-
Notifications
You must be signed in to change notification settings - Fork 64
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some thoughts. Would love @natebosch to weigh in too!
@@ -6,10 +6,10 @@ import 'package:built_collection/built_collection.dart'; | |||
|
|||
abstract class HasDartDocs { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add comments here and below why Object
is being used and what a valid type is (and isn't).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
Class( | ||
(b) => b | ||
..name = 'Foo' | ||
..docs.addAll( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part of me wonders if docs
should be a more complex class than a List
, i.e.:
class DocsBuilder {
void addText();
void addReference();
}
... WDUT? It would be more breaking, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started out with a much bigger change where I added a new class, DocComments
, and everything that HasDocComments today also got a @nullable DocComments
field. Then that class just had a List<Object>
, so that you could add Strings, and References.
Then I looked back and saw that I had really just created this unnecessary nesting, and confusion with the existing docs
field. And the emitter would probably have to have some weird logic in it saying "use one or the other." Essentially the new DocComment
type did not help with the List<Object>
issue.
If there was a way to hook into BuiltList, with validation logic, that would be tops. Then I could validate the type at runtime. Or add specific methods, addText
and addReference
. There isn't, is there? Would I subtype BuiltList/ListBuilder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I honestly am not sure. Let's wait and see what @natebosch says - we could also consult with @davidmorgan.
If you want this change as-is, I'm willing to approve. I do think we should consider making the interface better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope! I am definitely in favor of getting this right. And if creating a new field and adding "don't use both" logic to emitter is ultimately the right way, I'm game.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the recommended way to do that would be to make an interface Doc
and have built value classes Text
and Reference
that implement it. I don't think that can be a compatible change, unfortunately.
BuiltList can't do validation, you could validate in the class that has the list, a built_value can do validation in the private _
constructor, the fields are all initialized when it runs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ack
I do think it would be best to add a new field for this and deprecate the old one. I think we should move away from |
Sounds good. |
Work for dart-lang/tools#830. (I'm not sure what else is desired for that bug...)