[dart-misc] Introducing built_value.dart

[David Morgan ☯]

Hi Dartisans,

It's finally here: a lightweight code generation tool for immutable, easy
to work with value types

No more hand-coding hashCode, operator== or toString!

The example value type looks like too little code to do anything useful,
but as the test shows, the generated code turns it into a fully functional
class:

https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart

Coming next: JSON serialization support. And then you can really make
something nice with this :)

Cheers

Morgan

[Anders Holmgren]

Cool

[Anton Astashov]

Wow, that's already a third value object generator for the last 2 weeks!

Others:
https://pub.dartlang.org/packages/value_object
https://github.com/a14n/zengen#value

It definitely shows the need in that feature being supported natively. :)

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable, easy
to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything useful,
but as the test shows, the generated code turns it into a fully functional
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

[David Morgan ☯]

Ah, some competition. Cool :) ... and it's nice to see people getting to
grips with source_gen.

I would love for there to be more core language support.

What I haven't figured out yet is how to have a native feature that
supports builders. These should be mutable versions of the value types that
are allowed to be partial; it's important that they're a different type
from the value types, but they're nevertheless closely linked.

Still, just having native support for value types would be a big step
forward, I guess the builder part could be added on top.

Post by Anton Astashov
Wow, that's already a third value object generator for the last 2 weeks!
https://pub.dartlang.org/packages/value_object
https://github.com/a14n/zengen#value
It definitely shows the need in that feature being supported natively. :)

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable, easy
to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything useful,
but as the test shows, the generated code turns it into a fully functional
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

[Anders Holmgren]

I think in many cases you don't really need the builders.
It depends on how you use them.

Currently I'm reworking some functionally reactive code. So some object
changes and these get picked up on a stream by other objects that depend on
it which in turn update themselves and publish their new values on their
streams.

In that scenario I'm never creating a large graph of objects. Only ever one
layer at a time.

So value objects with named params in ctrs plus copy methods is all I need.

Of course in other use cases they are very valuable.

I wonder if the debate around Classes as first class objects could be
useful for builders. After all builders are just a fancy way of
constructing objects.
Never looked at languages like small talk that have them though

Post by David Morgan ☯
Ah, some competition. Cool :) ... and it's nice to see people getting to
grips with source_gen.
I would love for there to be more core language support.
What I haven't figured out yet is how to have a native feature that
supports builders. These should be mutable versions of the value types that
are allowed to be partial; it's important that they're a different type
from the value types, but they're nevertheless closely linked.
Still, just having native support for value types would be a big step
forward, I guess the builder part could be added on top.

Post by Anton Astashov
Wow, that's already a third value object generator for the last 2 weeks!
https://pub.dartlang.org/packages/value_object
https://github.com/a14n/zengen#value
It definitely shows the need in that feature being supported natively. :)

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything useful,
but as the test shows, the generated code turns it into a fully functional
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[David Morgan ☯]

One frustration I always had with named parameters is that there's no way
to tell if you got the default value because it wasn't passed or because
the default was passed.

This is of particular importance when the default is null, because it's
always possible that someone happened to pass in a null by mistake, and
would like you to throw a null pointer exception.

This is possible with builders because it's always explicit whether the
setter was called.

The other issue I have with named parameters is that, again because of the
defaults problem, it's hard to give alternatives for the same field.

For example, let's say I'd like to have three ways of setting the same
field: as raw value, as String that should be parsed, and a JSON blob. I
could name them "address", "stringAddress" and "jsonAddress". If someone
accidentally passes a null for one of the three then there's nothing I can
do, I can't even catch it.

With a builder, again, the explicit calling of setters makes it possible to
handle nulls correctly. (The "multiple ways to set one field" kind of needs
a builder anyway, at least compared to the builderless data type, since you
need to add code for it.)

Independ of value types, this is something I'd like to see fixed with named
parameters. I don't really have a suggestion for how, unfortunately ;)

Post by Anders Holmgren
I think in many cases you don't really need the builders.
It depends on how you use them.
Currently I'm reworking some functionally reactive code. So some object
changes and these get picked up on a stream by other objects that depend on
it which in turn update themselves and publish their new values on their
streams.
In that scenario I'm never creating a large graph of objects. Only ever
one layer at a time.
So value objects with named params in ctrs plus copy methods is all I need.
Of course in other use cases they are very valuable.
I wonder if the debate around Classes as first class objects could be
useful for builders. After all builders are just a fancy way of
constructing objects.
Never looked at languages like small talk that have them though

Post by David Morgan ☯
Ah, some competition. Cool :) ... and it's nice to see people getting to
grips with source_gen.
I would love for there to be more core language support.
What I haven't figured out yet is how to have a native feature that
supports builders. These should be mutable versions of the value types that
are allowed to be partial; it's important that they're a different type
from the value types, but they're nevertheless closely linked.
Still, just having native support for value types would be a big step
forward, I guess the builder part could be added on top.

Post by Anton Astashov
Wow, that's already a third value object generator for the last 2 weeks!
https://pub.dartlang.org/packages/value_object
https://github.com/a14n/zengen#value
It definitely shows the need in that feature being supported natively. :)

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything
useful, but as the test shows, the generated code turns it into a fully
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[tatumizer-v0.2]

Post by David Morgan ☯
Independ of value types, this is something I'd like to see fixed with

named parameters. I don't really have a suggestion for how, unfortunately ;)

There used to be a way to find out whether parameter was passed or not. It
was ugly. Very ugly. Eventually, the feature was removed. Huge celebration
ensued on this mailing list. One of the happiest moments I can remember.

There were logical problems with the feature (other than from ugliness).
Was null passed by mistake? Or was it passed intentionally, as instruction
to use default value, whatever it was?
E.g. you have address and shippingAddress. Null passed for shippingAddress
means: use address as shipping address. It's not a mistake.

Or, consider the function
"apply": https://api.dartlang.org/1.12.1/dart-core/Function/apply.html.
With the map (last parameter of "apply"), you have no way to say: value is
omitted. If value is omitted, it will look like null anyway. (BTW, in dart,
"apply" is a normal function, not something available only via reflection
like in java).

Had the constructor been a normal function, too, "apply" would do wonders.
Unfortunately, "apply" doesn't apply to constructor right now. But it will
be (if I am not mistaken, it's planned).

Back to the problem of detection of what was passed: I think good solution
would be to introduce different flavors of null. Many nulls.
For reason I don't understand, the idea didn't win a lot of fans. Too bad.

E.g. suppose you had constructor const Null(String). Then you could have
const Null("useDefault") and then use it like this:
const useDefault=const Null("useDefault");
const
class Foo {
int x;
Foo({x:useDefault}) { ...}
}

because constant useDefault IS null, it's assignment-compatible with every
other type. And it cannot be confused with any other null - e.g. the one
passed by mistake.
But it's not even a major use case for flavored nulls. Long story...

Back to the issue at hand: you can use appropriate constants as default
right now (instead of nulls), but you will need a specific constant per
type. e.g.
const Map useDefault = const {};
class Foo {
final Map json;
Foo({json: useDefault}) {

if (identical(json, useDefault)) {
// parameter was not passed
...
} else if (json == null) {
throw "blah blah";
} else {
this.json=json;
}
}
}
Now you can find out what was passed and what was omitted.
Flavored nulls would make the feature more uniform across different types..

['David "Morgan" Morgan' via Dart Misc]

Yeah, it's a fun topic.

Not sure about more nulls, the one we've got already seems problematic
enough. But I don't really have another suggestion.

Post by tatumizer-v0.2

Post by David Morgan ☯
Independ of value types, this is something I'd like to see fixed with

named parameters. I don't really have a suggestion for how, unfortunately ;)
There used to be a way to find out whether parameter was passed or not. It
was ugly. Very ugly. Eventually, the feature was removed. Huge celebration
ensued on this mailing list. One of the happiest moments I can remember.
There were logical problems with the feature (other than from ugliness).
Was null passed by mistake? Or was it passed intentionally, as instruction
to use default value, whatever it was?
E.g. you have address and shippingAddress. Null passed for shippingAddress
means: use address as shipping address. It's not a mistake.
https://api.dartlang.org/1.12.1/dart-core/Function/apply.html.
With the map (last parameter of "apply"), you have no way to say: value is
omitted. If value is omitted, it will look like null anyway. (BTW, in dart,
"apply" is a normal function, not something available only via reflection
like in java).
Had the constructor been a normal function, too, "apply" would do
wonders. Unfortunately, "apply" doesn't apply to constructor right now. But
it will be (if I am not mistaken, it's planned).
Back to the problem of detection of what was passed: I think good solution
would be to introduce different flavors of null. Many nulls.
For reason I don't understand, the idea didn't win a lot of fans. Too bad.
E.g. suppose you had constructor const Null(String). Then you could have
const useDefault=const Null("useDefault");
const
class Foo {
int x;
Foo({x:useDefault}) { ...}
}
because constant useDefault IS null, it's assignment-compatible with every
other type. And it cannot be confused with any other null - e.g. the one
passed by mistake.
But it's not even a major use case for flavored nulls. Long story...
Back to the issue at hand: you can use appropriate constants as default
right now (instead of nulls), but you will need a specific constant per
type. e.g.
const Map useDefault = const {};
class Foo {
final Map json;
Foo({json: useDefault}) {
if (identical(json, useDefault)) {
// parameter was not passed
...
} else if (json == null) {
throw "blah blah";
} else {
this.json=json;
}
}
}
Now you can find out what was passed and what was omitted.
Flavored nulls would make the feature more uniform across different types..
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[Anders Holmgren]

True. Defaults on named parameters are next to useless in Dart and increasingly I tend to avoid them.

I was hoping there was a way to fix / improve them as part of implementing NNBD. In that case if it is a non nullable parameter then passing a null should always mean use the default.

Incidentally, I would imagine that the percentage of cases where the user wants passing null to mean 'use null' rather than 'use the default' would be vanishingly small. Don't think that I have ever wanted that. IMO if there is a chance the caller would want a parameter to be null then the parameter shouldn't have a default.

I agree that the '"address", "stringAddress" and "jsonAddress"' case is firmly in the builder territory. Still I would imagine it is not a high percentage that are like this so I would still maintain that not all value objects need builders, but they are great when you do need them

[Lukas Renggli]

Post by David Morgan ☯
One frustration I always had with named parameters is that there's no way
to tell if you got the default value because it wasn't passed or because
the default was passed.

You could tell like so:

const _undefined = const Object();

void method({value: _undefined}) {
if (_undefined == value) {
print('default value requested');
} else if (null == value) {
print('null value request');
} else {
print('$value requested');
}
}


Not sure if I'd liked to write that myself, but it should work well enough
for generated code.

Cheers,
Lukas

This is of particular importance when the default is null, because it's

Post by David Morgan ☯
always possible that someone happened to pass in a null by mistake, and
would like you to throw a null pointer exception.
This is possible with builders because it's always explicit whether the
setter was called.
The other issue I have with named parameters is that, again because of the
defaults problem, it's hard to give alternatives for the same field.
For example, let's say I'd like to have three ways of setting the same
field: as raw value, as String that should be parsed, and a JSON blob. I
could name them "address", "stringAddress" and "jsonAddress". If someone
accidentally passes a null for one of the three then there's nothing I can
do, I can't even catch it.
With a builder, again, the explicit calling of setters makes it possible
to handle nulls correctly. (The "multiple ways to set one field" kind of
needs a builder anyway, at least compared to the builderless data type,
since you need to add code for it.)
Independ of value types, this is something I'd like to see fixed with
named parameters. I don't really have a suggestion for how, unfortunately ;)

Post by Anders Holmgren
I think in many cases you don't really need the builders.
It depends on how you use them.
Currently I'm reworking some functionally reactive code. So some object
changes and these get picked up on a stream by other objects that depend on
it which in turn update themselves and publish their new values on their
streams.
In that scenario I'm never creating a large graph of objects. Only ever
one layer at a time.
So value objects with named params in ctrs plus copy methods is all I need.
Of course in other use cases they are very valuable.
I wonder if the debate around Classes as first class objects could be
useful for builders. After all builders are just a fancy way of
constructing objects.
Never looked at languages like small talk that have them though

Post by David Morgan ☯
Ah, some competition. Cool :) ... and it's nice to see people getting to
grips with source_gen.
I would love for there to be more core language support.
What I haven't figured out yet is how to have a native feature that
supports builders. These should be mutable versions of the value types that
are allowed to be partial; it's important that they're a different type
from the value types, but they're nevertheless closely linked.
Still, just having native support for value types would be a big step
forward, I guess the builder part could be added on top.

Post by Anton Astashov
Wow, that's already a third value object generator for the last 2 weeks!
https://pub.dartlang.org/packages/value_object
https://github.com/a14n/zengen#value
It definitely shows the need in that feature being supported natively. :)

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything
useful, but as the test shows, the generated code turns it into a fully
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Lukas Renggli
www.lukas-renggli.ch

['Lasse R.H. Nielsen' via Dart Misc]

It is, luckily, fairly rare that a function both accepts null as an
argument and has a default value different from null, but it does happen.
We tried having a way to detect whether an argument was passed or not (I
forget the syntax, but it contained a question mark, probably something
like ?x - a bool which is true if a parameter was passed, false if it
retained its default value).
It was, as stated above, worse than the problem it tried to solve.
With this operator, you could no longer forward a default value.

helper(x, [y]) => bar(x, y); // forwards default value.
tuple(x, [y]) => ?y ? "($x, $y)" : "($x)";

Now, if you write helper(2) , you still get "(2, null)" as result because
forwarding the y parameter means that it is no longer omitted in the tuple
function.
We ended up having to write:
helper(x, [y]) => ?y ? bar(x, y) : bar(x);
everywhere. We were seriously contemplating adding a way to optionally pass
a parameter, but in the end it was decided that removing the ?x operator
was better.

So, now you can't have a default parameter that is also a valid parameter
and treat them differently. That's pretty reasonable, actually. It's just
the cases where you need to accept null and all values and also detect the
omitted parameter - I would recommend making a different function in that
case.

/L

Post by Lukas Renggli

Post by David Morgan ☯
One frustration I always had with named parameters is that there's no way
to tell if you got the default value because it wasn't passed or because
the default was passed.

const _undefined = const Object();
void method({value: _undefined}) {
if (_undefined == value) {
print('default value requested');
} else if (null == value) {
print('null value request');
} else {
print('$value requested');
}
}
Not sure if I'd liked to write that myself, but it should work well enough
for generated code.
Cheers,
Lukas
This is of particular importance when the default is null, because it's

Post by David Morgan ☯
always possible that someone happened to pass in a null by mistake, and
would like you to throw a null pointer exception.
This is possible with builders because it's always explicit whether the
setter was called.
The other issue I have with named parameters is that, again because of
the defaults problem, it's hard to give alternatives for the same field.
For example, let's say I'd like to have three ways of setting the same
field: as raw value, as String that should be parsed, and a JSON blob. I
could name them "address", "stringAddress" and "jsonAddress". If someone
accidentally passes a null for one of the three then there's nothing I can
do, I can't even catch it.
With a builder, again, the explicit calling of setters makes it possible
to handle nulls correctly. (The "multiple ways to set one field" kind of
needs a builder anyway, at least compared to the builderless data type,
since you need to add code for it.)
Independ of value types, this is something I'd like to see fixed with
named parameters. I don't really have a suggestion for how, unfortunately ;)

Post by Anders Holmgren
I think in many cases you don't really need the builders.
It depends on how you use them.
Currently I'm reworking some functionally reactive code. So some object
changes and these get picked up on a stream by other objects that depend on
it which in turn update themselves and publish their new values on their
streams.
In that scenario I'm never creating a large graph of objects. Only ever
one layer at a time.
So value objects with named params in ctrs plus copy methods is all I need.
Of course in other use cases they are very valuable.
I wonder if the debate around Classes as first class objects could be
useful for builders. After all builders are just a fancy way of
constructing objects.
Never looked at languages like small talk that have them though

Post by David Morgan ☯
Ah, some competition. Cool :) ... and it's nice to see people getting
to grips with source_gen.
I would love for there to be more core language support.
What I haven't figured out yet is how to have a native feature that
supports builders. These should be mutable versions of the value types that
are allowed to be partial; it's important that they're a different type
from the value types, but they're nevertheless closely linked.
Still, just having native support for value types would be a big step
forward, I guess the builder part could be added on top.

Post by Anton Astashov
Wow, that's already a third value object generator for the last 2 weeks!
https://pub.dartlang.org/packages/value_object
https://github.com/a14n/zengen#value
It definitely shows the need in that feature being supported natively. :)

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything
useful, but as the test shows, the generated code turns it into a fully
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Lukas Renggli
www.lukas-renggli.ch
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Lasse R.H. Nielsen - ***@google.com
'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

['Paul Brauner' via Dart Misc]

Post by Lukas Renggli

Post by David Morgan ☯
One frustration I always had with named parameters is that there's no way
to tell if you got the default value because it wasn't passed or because
the default was passed.

const _undefined = const Object();
void method({value: _undefined}) {
if (_undefined == value) {
print('default value requested');
} else if (null == value) {
print('null value request');
} else {
print('$value requested');
}
}
Not sure if I'd liked to write that myself, but it should work well enough
for generated code.

I did it once, on manually written code, for the copy method of an
immutable object :) It's here
<https://github.com/polux/parsers/blob/master/lib/parsers.dart#L103>.

Post by Lukas Renggli
Cheers,
Lukas
This is of particular importance when the default is null, because it's

Post by David Morgan ☯
always possible that someone happened to pass in a null by mistake, and
would like you to throw a null pointer exception.
This is possible with builders because it's always explicit whether the
setter was called.
The other issue I have with named parameters is that, again because of
the defaults problem, it's hard to give alternatives for the same field.
For example, let's say I'd like to have three ways of setting the same
field: as raw value, as String that should be parsed, and a JSON blob. I
could name them "address", "stringAddress" and "jsonAddress". If someone
accidentally passes a null for one of the three then there's nothing I can
do, I can't even catch it.
With a builder, again, the explicit calling of setters makes it possible
to handle nulls correctly. (The "multiple ways to set one field" kind of
needs a builder anyway, at least compared to the builderless data type,
since you need to add code for it.)
Independ of value types, this is something I'd like to see fixed with
named parameters. I don't really have a suggestion for how, unfortunately ;)

Post by Anders Holmgren
I think in many cases you don't really need the builders.
It depends on how you use them.
Currently I'm reworking some functionally reactive code. So some object
changes and these get picked up on a stream by other objects that depend on
it which in turn update themselves and publish their new values on their
streams.
In that scenario I'm never creating a large graph of objects. Only ever
one layer at a time.
So value objects with named params in ctrs plus copy methods is all I need.
Of course in other use cases they are very valuable.
I wonder if the debate around Classes as first class objects could be
useful for builders. After all builders are just a fancy way of
constructing objects.
Never looked at languages like small talk that have them though

Post by David Morgan ☯
Ah, some competition. Cool :) ... and it's nice to see people getting
to grips with source_gen.
I would love for there to be more core language support.
What I haven't figured out yet is how to have a native feature that
supports builders. These should be mutable versions of the value types that
are allowed to be partial; it's important that they're a different type
from the value types, but they're nevertheless closely linked.
Still, just having native support for value types would be a big step
forward, I guess the builder part could be added on top.

Post by Anton Astashov
Wow, that's already a third value object generator for the last 2 weeks!
https://pub.dartlang.org/packages/value_object
https://github.com/a14n/zengen#value
It definitely shows the need in that feature being supported natively. :)

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything
useful, but as the test shows, the generated code turns it into a fully
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Lukas Renggli
www.lukas-renggli.ch
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[kc]

Is this and your other Dart work for Angular 2.0?

K.

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable, easy
to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything useful,
but as the test shows, the generated code turns it into a fully functional
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

['David "Morgan" Morgan' via Dart Misc]

Not specifically, but we'll be using them with Angular 2, so if there's any
work needed to make them fit nicely then we might make a few tweaks.

Post by kc
Is this and your other Dart work for Angular 2.0?
K.

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable, easy
to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything useful,
but as the test shows, the generated code turns it into a fully functional
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[kc]

Just out of interest - what's the context/prompt for the
build_value/build_collection/enum_class.dart projects in google?

K.

Post by 'David "Morgan" Morgan' via Dart Misc
Not specifically, but we'll be using them with Angular 2, so if there's
any work needed to make them fit nicely then we might make a few tweaks.

Post by kc
Is this and your other Dart work for Angular 2.0?
K.

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything useful,
but as the test shows, the generated code turns it into a fully functional
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

['David "Morgan" Morgan' via Dart Misc]

Good question.

My team is not at all part of the Dart team, rather we're a user of Dart.
The project is one you've almost certainly not used ;) AdWords for video,
part of adwords.google.com. We sell YouTube ads, the ones with the skip
button :) ... it's a large, complex and revenue critical UI.

As part of building this UI in Dart we built some infrastructure that we
felt we needed. It's more or less functionally equivalent to what's now
being open sourced. But, it was written quite some time ago, so we couldn't
take advantage of nice things like the recent analyzer versions and
source_gen. The open source versions are rewrites more in the spirit of
what's now available for Dart, and with the aim of keeping up with expected
changes to Dart (like non-nullable types).

As to why open source ... because we can :) ... and because we can better
integrate/interoperate with other open source projects like Angular and
Dart itself if we're on the same playing field. I'm also personally excited
about bringing the technology we've built on (pun intended) so successfully
to the wider Dart community.

Post by kc
Just out of interest - what's the context/prompt for the
build_value/build_collection/enum_class.dart projects in google?
K.

Post by 'David "Morgan" Morgan' via Dart Misc
Not specifically, but we'll be using them with Angular 2, so if there's
any work needed to make them fit nicely then we might make a few tweaks.

Post by kc
Is this and your other Dart work for Angular 2.0?
K.

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything
useful, but as the test shows, the generated code turns it into a fully
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[Anders Holmgren]

Thanks a lot for your contributions.

I think it is great to see non Dart team googlers contributing to the community.

If dart usage is growing inside google, as the dart team tells us, then it is very important to leverage that to help dart grow outside google.

[kc]

Very interesting.

Are build_value/build_collection/enum_class.dart used in a React style by
the AdWords UI?

Good if your real world usage/experience flows through into core Dart
language/runtime support.

K.

Post by 'David "Morgan" Morgan' via Dart Misc
Good question.
My team is not at all part of the Dart team, rather we're a user of Dart.
The project is one you've almost certainly not used ;) AdWords for video,
part of adwords.google.com. We sell YouTube ads, the ones with the skip
button :) ... it's a large, complex and revenue critical UI.
As part of building this UI in Dart we built some infrastructure that we
felt we needed. It's more or less functionally equivalent to what's now
being open sourced. But, it was written quite some time ago, so we couldn't
take advantage of nice things like the recent analyzer versions and
source_gen. The open source versions are rewrites more in the spirit of
what's now available for Dart, and with the aim of keeping up with expected
changes to Dart (like non-nullable types).
As to why open source ... because we can :) ... and because we can better
integrate/interoperate with other open source projects like Angular and
Dart itself if we're on the same playing field. I'm also personally excited
about bringing the technology we've built on (pun intended) so successfully
to the wider Dart community.

Post by kc
Just out of interest - what's the context/prompt for the
build_value/build_collection/enum_class.dart projects in google?
K.

Post by 'David "Morgan" Morgan' via Dart Misc
Not specifically, but we'll be using them with Angular 2, so if there's
any work needed to make them fit nicely then we might make a few tweaks.

Post by kc
Is this and your other Dart work for Angular 2.0?
K.

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything
useful, but as the test shows, the generated code turns it into a fully
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

['David "Morgan" Morgan' via Dart Misc]

We build in Angular (and soon Angular 2) with a heavy focus on use of
immutable types, but other than that, nothing special.

Honor compels me to point out that we're just a small part of the AdWords
UI codebase/team. I can't speak for the other parts (search, display, many
others).

Post by kc
Very interesting.
Are build_value/build_collection/enum_class.dart used in a React style by
the AdWords UI?
Good if your real world usage/experience flows through into core Dart
language/runtime support.
K.

Post by 'David "Morgan" Morgan' via Dart Misc
Good question.
My team is not at all part of the Dart team, rather we're a user of Dart.
The project is one you've almost certainly not used ;) AdWords for video,
part of adwords.google.com. We sell YouTube ads, the ones with the skip
button :) ... it's a large, complex and revenue critical UI.
As part of building this UI in Dart we built some infrastructure that we
felt we needed. It's more or less functionally equivalent to what's now
being open sourced. But, it was written quite some time ago, so we couldn't
take advantage of nice things like the recent analyzer versions and
source_gen. The open source versions are rewrites more in the spirit of
what's now available for Dart, and with the aim of keeping up with expected
changes to Dart (like non-nullable types).
As to why open source ... because we can :) ... and because we can better
integrate/interoperate with other open source projects like Angular and
Dart itself if we're on the same playing field. I'm also personally excited
about bringing the technology we've built on (pun intended) so successfully
to the wider Dart community.

Post by kc
Just out of interest - what's the context/prompt for the
build_value/build_collection/enum_class.dart projects in google?
K.

Post by 'David "Morgan" Morgan' via Dart Misc
Not specifically, but we'll be using them with Angular 2, so if there's
any work needed to make them fit nicely then we might make a few tweaks.

Post by kc
Is this and your other Dart work for Angular 2.0?
K.

Post by David Morgan ☯
Hi Dartisans,
It's finally here: a lightweight code generation tool for immutable,
easy to work with value types.
No more hand-coding hashCode, operator== or toString!
The example value type looks like too little code to do anything
useful, but as the test shows, the generated code turns it into a fully
https://github.com/google/built_value.dart/blob/master/example/lib/value.dart
https://github.com/google/built_value.dart/blob/master/example/test/value_test.dart
Coming next: JSON serialization support. And then you can really make
something nice with this :)
Cheers
Morgan

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new

[tatumizer-v0.2]

Post by 'Paul Brauner' via Dart Misc
I did it once, on manually written code, for the copy method of an

immutable object :) It's here
<https://github.com/polux/parsers/blob/master/lib/parsers.dart#L103>.
Looking into "here":
class Undefined { const Undefined(); }
...
ParseResult copy({String text, Expectations expectations, Position position,
bool isSuccess, bool isCommitted, *Object value: const Undefined()*}) {
...
}

So you defined a constant that is assignment-compatible with every Object.
Probably you find it useful, right? The problem is that you need to
sacrifice type type. Even if you know the type of "value" is int, you have
to still write it as Object (or dynamic).

This concept is obviously equivalent to flavored Null, it just wasn't
"institutionalized", hence it takes ad-hoc expression and makes you mangle
the type. Everyone will have to invent their own nulls, in their own ways.