[dart-misc] Notes from 9/30 DEP meeting

['Bob Nystrom' via Dart Misc]

Here's my notes!

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md

This is from *last* week's meeting. Sorry for the delay. There was no DEP
meeting this week.

Cheers!

– bob

[Jan Mostert]

+1 for default constructers!!

new C(foo: 42, bar: 10)


This will also solve the issue where I'm creating multiple constructors
simply to pass different parameters.

Post by 'Bob Nystrom' via Dart Misc
Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from *last* week's meeting. Sorry for the delay. There was no DEP
meeting this week.
Cheers!
– bob
--
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

[tatumizer-v0.2]

new Address()
..street = (new StreetAddress()
..number = 123
..street = (new Street()
..name = "Main"
..kind = "St."))
..city = "Springville"
..state = "Illinois";

That's the problem with cascade: it doesn't look good with nesting. It's
hard to write, hard to read, and generally weird.

I've given it a bit of philosophical thought over the years :)

Here is the summary of my findings so far:

Suppose you are writing a function, and it gets complicated, with nested
ifs, for(s) etc. Or just the body is too long - you get out of breath
trying to read it.
What do you do?

Sure, you define a bunch of simpler functions, with supposedly meaningful
names, and refactor the big one.
What stops you from doing the same wrt structured data as above?
E.g. you could write
var street= new Street()
..name= "Main"
..kind= "St.";
var streetAddress=new StreetAddress()
..number= 123
..street= street;
var address = new Address()
..streetAddress = streetAddress,
..city = "Springville"
..state = "Illinois";




It is much easier to read, but here's the problem: if you need more than
one address, you cannot reuse variables "street" and "streetAddress" - you
need "street1" and "streetAddress1" etc - which is ugly and error prone.

What to do? By the way, things don't get much different with any other data
notation. With JSON, you can write 1 more level of nesting before it gets
incomprehensible, but no more than that. With XML - maybe you can afford 2
extra levels, but the thing already looks monumental and a bit of out of
place in a programming language.

I'm afraid generated constructor will not get you past level 2 anyway.

Whether a good solution exists, I don't know. Maybe if we had "blocks
returning a value" (we discussed it in another thread) we could achieve
the same result, but at least those blocks can be used also for
initialization of variables (so the feature is not as ad-hoc as generated
constructor).
I find the syntax (){ ... return 1;}() atrocious, so maybe special kind of
"auto-executed block" can be introduced, like
var x=${
//any code that uses return statements

}

Then you could write it like this:
var address = ${
var street= new Street()
..name= "Main"
..kind= "St.";
var streetAddress=new StreetAddress()
..number= 123
..street= street;

return new Address()
..streetAddress = streetAddress,
..city = "Springville"
..state = "Illinois";
}

How about that? (BTW, this seems to be backward compatible, no?)

['Brian Slesinsky' via Dart Misc]

An improved default constructor seems interesting for the case where you
have lots of simple record-like types with lots of fields. They tend to be
a mix of required and optional fields though. So, suppose we combine this
with non-null field types? If the field is final and allows null, it's
optional in the constructor. If it's final and doesn't allow null, it's
required.

I ran into something vaguely similar while implementing a virtual DOM for
TagTree. Every HTML element has lots of attributes. It's tedious to write
all the attributes more than once, even in the skeleton DOM I wrote that
was far from complete.

However, in TagTree, I would have found tear-off constructors more useful.
In that case I was duplicating long lists of keyword parameters in create()
functions that just call constructors.

So, this would *also* play well with tear off constructors. If we have nice
default constructors and we can tear them off, it seems like we end up with
a way to create a function that returns its parameters as a simple,
immutable record object. So we get a concise way to define a schema of
record objects and a collection of functions to build them, with no
duplication of field names or types.

- Brian


On Fri, Oct 9, 2015 at 10:48 AM, 'Bob Nystrom' via Dart Core Development <

Post by 'Bob Nystrom' via Dart Misc
Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from *last* week's meeting. Sorry for the delay. There was no DEP
meeting this week.
Cheers!
– bob
--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by 'Brian Slesinsky' via Dart Misc
An improved default constructor seems interesting for the case where you
have lots of simple record-like types with lots of fields. They tend to be
a mix of required and optional fields though. So, suppose we combine this
with non-null field types? If the field is final and allows null, it's
optional in the constructor. If it's final and doesn't allow null, it's
required.

Alas, we don't have required named parameters. I don't think the parameters
should be positional because it would mean that order of field declarations
would affect your public API.

I would be excited to add required named parameters too, but that's a whole
other ball of work.

Post by 'Brian Slesinsky' via Dart Misc
I ran into something vaguely similar while implementing a virtual DOM for
TagTree. Every HTML element has lots of attributes. It's tedious to write
all the attributes more than once, even in the skeleton DOM I wrote that
was far from complete.
However, in TagTree, I would have found tear-off constructors more useful.
In that case I was duplicating long lists of keyword parameters in create()
functions that just call constructors.
So, this would *also* play well with tear off constructors. If we have
nice default constructors and we can tear them off, it seems like we end up
with a way to create a function that returns its parameters as a simple,
immutable record object. So we get a concise way to define a schema of
record objects and a collection of functions to build them, with no
duplication of field names or types.

I would love to be able to tear off constructors.

– bob

['Brian Slesinsky' via Dart Misc]

Post by 'Bob Nystrom' via Dart Misc
Alas, we don't have required named parameters. I don't think the
parameters should be positional because it would mean that order of field
declarations would affect your public API.

So what happens if you initialize a not-null final field with a named
parameter? Will that be disallowed?

['Bob Nystrom' via Dart Misc]

Post by 'Brian Slesinsky' via Dart Misc
So what happens if you initialize a not-null final field with a named
parameter? Will that be disallowed?

I think that's one of the open edge case questions about non-nullability. I
think it would probably be disallowed if it doesn't have a default value.

– bob

[kc]

Maybe Dart could use something like Kotlins data classes based on the
syntax suggested by Lasse. Would play well when working with data/POD's and
gRPC/protobufs.

https://kotlinlang.org/docs/reference/data-classes.html

I've often thought Dart could use three core object types:
- reference objects (Dart's current classes)
- value objects (small immutable objects String, Date, Url)
- data objects (can only contain value objects or other data objects)

K.

Post by 'Brian Slesinsky' via Dart Misc
An improved default constructor seems interesting for the case where you
have lots of simple record-like types with lots of fields. They tend to be
a mix of required and optional fields though. So, suppose we combine this
with non-null field types? If the field is final and allows null, it's
optional in the constructor. If it's final and doesn't allow null, it's
required.
I ran into something vaguely similar while implementing a virtual DOM for
TagTree. Every HTML element has lots of attributes. It's tedious to write
all the attributes more than once, even in the skeleton DOM I wrote that
was far from complete.
However, in TagTree, I would have found tear-off constructors more useful.
In that case I was duplicating long lists of keyword parameters in create()
functions that just call constructors.
So, this would *also* play well with tear off constructors. If we have
nice default constructors and we can tear them off, it seems like we end up
with a way to create a function that returns its parameters as a simple,
immutable record object. So we get a concise way to define a schema of
record objects and a collection of functions to build them, with no
duplication of field names or types.
- Brian
On Fri, Oct 9, 2015 at 10:48 AM, 'Bob Nystrom' via Dart Core Development <

Post by 'Bob Nystrom' via Dart Misc
Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from *last* week's meeting. Sorry for the delay. There was no
DEP meeting this week.
Cheers!
– bob
--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Anders Holmgren]

+1 for koltin like value classes. I find value objects so common and would love to see first class language support

[kc]

I like this attitude:

For example, *the Flutter folks, and the Dart VM team supporting them, are

going to do what they need to make their product successful.* We've seen
the same thing in dart4web and Fletch.
...
Our task is to* improve the overall language in ways that all of the
implementation teams are excited about*. In some ways, they're our
customer. Meanwhile, they may come up with something that makes sense for
them but not the other implementations. We can try to generalize it to
something useful across the whole system, or help them, or* let them do
it on their own.*

To be honest The Spec and TC52 are a bit of a millstone at the moment.
Project needs a bit of freedom of movement to kill on mobile. Then back to
the server.

K.

Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from *last* week's meeting. Sorry for the delay. There was no DEP
meeting this week.
Cheers!
– bob

[kc]

Who is product manager and/or tech lead for Dart/Dart VM in terms of work
with Flutter?

K.

Post by 'Bob Nystrom' via Dart Misc
Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from *last* week's meeting. Sorry for the delay. There was no DEP
meeting this week.
Cheers!
– bob

['Andreas Kirsch' via Dart Misc]

+1 for improved default constructors!

And +1 to allowing any object as assert param and inspecting that in the
debugger/calling toString as late as possible.

I think in general, we sometimes cast things to string too early in
exception handling code and lose a lot of debugging options (eg in Angular1
they do that a lot).

Post by kc
Who is product manager and/or tech lead for Dart/Dart VM in terms of work
with Flutter?
K.

Post by 'Bob Nystrom' via Dart Misc
Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from *last* week's meeting. Sorry for the delay. There was no
DEP meeting this week.
Cheers!
– bob

--
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

--
Why is this e-mail so short? Answer: five.sentenc.es.

[Günter Zöchbauer]

I like the improved default constructor but I am also interested how getting rid of constructors could look like.

Post by 'Andreas Kirsch' via Dart Misc
+1 for improved default constructors!
And +1 to allowing any object as assert param and inspecting that in the debugger/calling toString as late as possible.
I think in general, we sometimes cast things to string too early in exception handling code and lose a lot of debugging options (eg in Angular1 they do that a lot).
Who is product manager and/or tech lead for Dart/Dart VM in terms of work with Flutter?
K.
Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from last week's meeting. Sorry for the delay. There was no DEP meeting this week.
Cheers!
– bob
--
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
--
Why is this e-mail so short? Answer: five.sentenc.es.

[tatumizer-v0.2]

There is a couple of corner cases for proposed generated constructor. E.g.
foo()=>1;
class Bar {
var value=foo();
}
constructor with named parameters cannot be generated because foo() is not
a constant expression. No easy way out (at least until the constness
requirement for named parameters is removed).
But even if it is removed, then it's not quite clear how many times
function foo will be called - one or two.

Another example:
class Bar {
final value=15;
// try to add constructor:
Bar({this.value:15});
}
Currently, this is a warning: 'value' is final and was given a value when
it was declared, so it cannot be set to a new value

Perhaps, this constructor should be requested by special class annotation.
Not everyone who wants default constructor will want as well a constructor
with 50 parameters. Imagine API doc for this.

@Gunter: you can define explicit constructor like Foo._() - then default
constructor will not materialize. (If I understood your question correctly)

[David Morgan ☯]

This discussion coincides nicely with the first release of built_value.dart
... https://github.com/google/built_value.dart

There's no way to use named parameters that is as flexible and powerful as
builders.

For nesting, the builders need to know about nested buildable types, so
they can be handled correctly. (Builders should store nested builders, not
nested built values).

Here's the example from up thread:

new Address()
..street = (new StreetAddress()
..number = 123
..street = (new Street()
..name = "Main"
..kind = "St."))
..city = "Springville"
..state = "Illinois";

And here is what it looks like with built_value.dart. You actually have a
choice about how much to nest. You can write it completely flat:

new Address((b) => b
..street.number = 123
..street.street.name = 'Main'
..street.street.kind = 'St.'
..city = 'Springville'
..state = 'Illinois');

Or nest another level in:

new Address((b) => b
..street.update((b) => b
..number = 123
..street.name = 'Main'
..street.kind = 'St.')
..city = 'Springville'
..state = 'Illinois');

Or nest completely:

new Address((b) => b
..street.update((b) => b
..number = 123
..street.update((b) => b
..name = 'Main'
..kind = 'St.'))
..city = 'Springville'
..state = 'Illinois');

And of course you can also split into multiple statements, and reuse nested
pieces if you like:

var builder = new AddressBuilder()..update((b) => b..street.number = 123);
builder.street.street..name = 'Main'..kind = 'St.';
builder..city = 'Springville'..state = 'Illinois';
var address = builder.build();

And re: required fields, built_value makes them required by default, with a
@nullable annotation if they're not required.

In short, built_value is intended to be a complete solution for value
types. If there's anything missing, please let me know :)

(Okay, well, JSON serialization is missing, but that's coming).

Cheers

Morgan

Post by tatumizer-v0.2
There is a couple of corner cases for proposed generated constructor. E.g.
foo()=>1;
class Bar {
var value=foo();
}
constructor with named parameters cannot be generated because foo() is not
a constant expression. No easy way out (at least until the constness
requirement for named parameters is removed).
But even if it is removed, then it's not quite clear how many times
function foo will be called - one or two.
class Bar {
final value=15;
Bar({this.value:15});
}
Currently, this is a warning: 'value' is final and was given a value when
it was declared, so it cannot be set to a new value
Perhaps, this constructor should be requested by special class annotation.
Not everyone who wants default constructor will want as well a constructor
with 50 parameters. Imagine API doc for this.
@Gunter: you can define explicit constructor like Foo._() - then default
constructor will not materialize. (If I understood your question correctly)

[kc]

Post by David Morgan ☯
This discussion coincides nicely with the first release of
built_value.dart ... https://github.com/google/built_value.dart
There's no way to use named parameters that is as flexible and powerful as
builders.
For nesting, the builders need to know about nested buildable types, so
they can be handled correctly. (Builders should store nested builders, not
nested built values).

Flutter is also using the React (immutable) tree of value objects approach.
Though Flutter seems to be using named parameters and constructors (with
inheritance) to define structures.

Could both Flutter and Angular(?) use syntax/semantics support for 'data'
objects that can only contain value objects.

Post by David Morgan ☯
new Address()
..street = (new StreetAddress()
..number = 123
..street = (new Street()
..name = "Main"
..kind = "St."))
..city = "Springville"
..state = "Illinois";
And here is what it looks like with built_value.dart. You actually have a
new Address((b) => b
..street.number = 123
..street.street.name = 'Main'
..street.street.kind = 'St.'
..city = 'Springville'
..state = 'Illinois');

'data' objects with some syntax:

var addr = Address {
street.number : 123
street.street.name : 'Main'
street.street.kind : 'St.'
city : 'Springville'
state : 'Illinois' };

// update
addr. {
street.number: 456;
}

// immutable
addr.close();


Overall, C# 7 has a theme which could be useful for Dart 2.0:

*Working with data*


Today’s programs are connected and trade in rich, structured data: it’s

Post by David Morgan ☯
what’s on the wire, it’s what apps and services produce, manipulate and
consume.
Traditional object-oriented modeling is good for many things, but in many
ways it deals rather poorly with this setup: it bunches functionality
strongly with the data (through encapsulation), and often relies heavily on
mutation of that state. It is "behavior-centric" instead of "data-centric".
Functional programming languages are often better set up for this: data is
immutable (representing information, not state), and is manipulated from
the outside, using a freely growable and context-dependent set of
functions, rather than a fixed set of built-in virtual methods. Let’s
continue being inspired by functional languages, and in particular other
languages – F#, Scala, Swift – that aim to mix functional and
object-oriented concepts as smoothly as possible.

https://github.com/dotnet/roslyn/issues/98

K.

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

All interesting stuff, thanks. Just one comment...

// immutable

Post by kc
addr.close();

I'm skeptical about dynamic approaches to immutability. (...which I assume
this is, perhaps I misunderstood). I'd like static checking for when I try
to pass a partial/mutable instance in place of a complete/valid/immutable
one.

[kc]

Post by 'David "Morgan" Morgan' via Dart Misc
All interesting stuff, thanks. Just one comment...
// immutable

Post by kc
addr.close();

I'm skeptical about dynamic approaches to immutability. (...which I assume
this is, perhaps I misunderstood). I'd like static checking for when I try
to pass a partial/mutable instance in place of a complete/valid/immutable
one.

Right, an immutable copy would be more appropriate.

Would be useful if the Dart/Flutter team members and yourself could put
your heads together to come up with something interesting for value
objects, immutable collections/structures and useful enums baked into
Dart's syntax and semantics.

K.

[tatumizer-v0.2]

[ Continued: ramblings about generated constructor ]
Compare 2 classes:
// variant A: original definition
class Foo {
final int value=42;
}
and
// variant B: definition with generated constructor
class Foo {
final int value;
Foo({this.value:42});
}

Obviously, these 2 definitions are not equivalent. In variant A, the value
is fixed (42), and can't be anything else.
In variant B, "42" is just a default - user can pass any other value.
However, that's not what definition of variant A meant: it wanted exactly
42, not anything else.

Here a (slightly contrived) example where this distinction is important.
class Point3D {
int x, y, z;
}
class Point2D {
final int z=0; // zero, and nothing else
}

Generating default constructor for Point2D accepting value of z would lead
to absurd.
So, at the very least, special annotation is needed to trigger generation
of constructor.

Another point: if you look at proposed generated constructor under certain
angle through polarized glasses, you will see that said constructor is none
other than static function fromMap
(and actually, it can be treated like this using "apply" - see parallel
thread).
Which leads to idea: annotate class with @generateMapView - and get
constructor, fromMap and toMap automatically. And that's all needed to
to/from json conversion, and for many other purposes (e.g. building
immutable values).

This idea pops up periodically on these pages. Would be good to know what
Bob and Lasse think about it.
.

[Günter Zöchbauer]

Post by tatumizer-v0.2
There is a couple of corner cases for proposed generated constructor. E.g.
foo()=>1;
class Bar {
   var value=foo();
}
constructor with named parameters cannot be generated because foo() is not a constant expression. No easy way out (at least until the constness requirement for named parameters is removed).
But even if it is removed, then it's not quite clear how many times function foo will be called - one or two.
 class Bar {
   final value=15;
   Bar({this.value:15});
}
Currently, this is a warning: 'value' is final and was given a value when it was declared, so it cannot be set to a new value
Perhaps, this constructor should be requested by special class annotation. Not everyone who wants default constructor will want as well a constructor with 50 parameters. Imagine API doc for this.
@Gunter: you can define explicit constructor like Foo._()  - then default constructor will not materialize. (If I understood your question correctly)

Bob mentioned in the document that Gilad wants to get rid of constructors entirely. I find this appealing because it would simplify the language a lot but I would like to know more about what consequences this change would have.

[Lingfeng Xu]

It would look really really familiar and attractive to whatever dynamic
language users, if the mentioned default constructor is presented like this:

Address address = new {
'street' : new {
'number' : 123,
'street' : new {
'name' : 'Main',
'kind' : 'St.',
},
},
'city' : 'Springville',
'state' : 'Illinois',
};

There may be some language inconsistency. But I personally think this is
syntax sweetness brought to pretty high level, especially to new comers.
Without "new" keywords, this is just a dart map object. Could consider
removing those quotes for keys.
Of cause this doesn't work with polymorphism. So maybe make the class name
after "new" optional.
Just my two cents.

I'm curious how removing constructors could work too. In my Dart learning
notes, constructors took nearly half length.

圚 2015幎10月9日星期五 UTC-7䞊午10:48:36Bob写道

Post by 'Bob Nystrom' via Dart Misc
Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from *last* week's meeting. Sorry for the delay. There was no DEP
meeting this week.
Cheers!
– bob

[tatumizer-v0.2]

I really like the idea. Actually, "new" is not necessary either. If objects
start generating "fromMap"and "toMap", normal json notation can be
considered as sugar for calling fromMap automatically.

[Daniel Joyce]

declarative / Object literal syntax is not that uncommon. JavaFX had it

You still need types though. Unless you are suggesting maps might
automatically converted to the proper types (assuming they weren't declared
'var'). But this gets complicated if the declared type for a object
property is a base type, and you want to assign a subclass to it.

var user = User {
firstName: "Bob",
lastName: "Anders",
home: Phone { number: "425-6789", ext: "444" },
work: Phone { number: "425-7777" },
...
}


class Foo

class Bar extends Foo {
String zib;
}

class Qux {
Foo foo1;
Foo foo2;
}

var qux = Qux {
foo1: Foo{}
foo2: Bar{ zib: "DERP" }
}

Post by tatumizer-v0.2
I really like the idea. Actually, "new" is not necessary either. If
objects start generating "fromMap"and "toMap", normal json notation can be
considered as sugar for calling fromMap automatically.
--
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

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

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

Subclassing doesn't make sense for value types: there's no way to implement
"equals" properly.

It should be enough to be able to add mixins and implement interfaces.

Post by Daniel Joyce
declarative / Object literal syntax is not that uncommon. JavaFX had it
You still need types though. Unless you are suggesting maps might
automatically converted to the proper types (assuming they weren't declared
'var'). But this gets complicated if the declared type for a object
property is a base type, and you want to assign a subclass to it.
var user = User {
firstName: "Bob",
lastName: "Anders",
home: Phone { number: "425-6789", ext: "444" },
work: Phone { number: "425-7777" },
...
}
class Foo
class Bar extends Foo {
String zib;
}
class Qux {
Foo foo1;
Foo foo2;
}
var qux = Qux {
foo1: Foo{}
foo2: Bar{ zib: "DERP" }
}

Post by tatumizer-v0.2
I really like the idea. Actually, "new" is not necessary either. If
objects start generating "fromMap"and "toMap", normal json notation can be
considered as sugar for calling fromMap automatically.
--
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

--
Daniel Joyce
The meek shall inherit the Earth, for the brave will be among the stars.
--
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]

Subclassing may not make sense for value objects, but if we discuss object
literals in general, subclassing is very much in play (e.g. for UI
components).
I never heard about javaFX before (anyone still using java for UI
programming? hm...), went to investigate.
I like the look and feel of their literals. Note how they write children
with no extra indentation:
https://blogs.oracle.com/sundararajan/entry/javascript_json_and_javafx_script

[Daniel Joyce]

JavaFX was pretty neat for building UIs, but Oracle killed it when they
bought sun. Now all the features are exposed via plain Java, which gives
java a very powerful but verbose scenegraph based UI library. Of course
being on the JVM, scala fx provides a dsl that keeps most of the flavor

http://www.scalafx.org/docs/home/

Really this kind of syntax makes building UIs super fast, and is easy to
cleanly support in UI building tools. It would be cool if there was a
declarative API for polymer dart, and using it would take care of all the
import/binding nonsense

Post by tatumizer-v0.2
Subclassing may not make sense for value objects, but if we discuss object
literals in general, subclassing is very much in play (e.g. for UI
components).
I never heard about javaFX before (anyone still using java for UI
programming? hm...), went to investigate.
I like the look and feel of their literals. Note how they write children
https://blogs.oracle.com/sundararajan/entry/javascript_json_and_javafx_script
--
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

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[kc]

Post by Daniel Joyce
JavaFX was pretty neat for building UIs, but Oracle killed it when they
bought sun. Now all the features are exposed via plain Java, which gives
java a very powerful but verbose scenegraph based UI library. Of course
being on the JVM, scala fx provides a dsl that keeps most of the flavor
http://www.scalafx.org/docs/home/

JavaxFX was nice. QML is also good.

Post by Daniel Joyce
Really this kind of syntax makes building UIs super fast, and is easy to
cleanly support in UI building tools. It would be cool if there was a
declarative API for polymer dart, and using it would take care of all the
import/binding nonsense

Would be good for Flutter.

K.

Post by Daniel Joyce

Post by tatumizer-v0.2
Subclassing may not make sense for value objects, but if we discuss
object literals in general, subclassing is very much in play (e.g. for UI
components).
I never heard about javaFX before (anyone still using java for UI
programming? hm...), went to investigate.
I like the look and feel of their literals. Note how they write children
https://blogs.oracle.com/sundararajan/entry/javascript_json_and_javafx_script
--
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

--
Daniel Joyce
The meek shall inherit the Earth, for the brave will be among the stars.

[Anders Holmgren]

Subclassing doesn't make sense for value types: there's no way to implement "equals" properly.

I don't understand that. What is the challenge with "equals"?

Why can't you do

class B extends A {
final String x;

bool operator==(other) => other is B && super.==(other) && other.x == x;
}

I admit I have never done that but always assume I could

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

The problem is that "b == a" and "a == b" will give you different answers.

Not cool at all ;)

You can make it symmetrical with double dispatch:

https://www.google.com/#q=double%20dispatch%20for%20subclass%20equals

...but there's still the question of what you actually want to happen,
there isn't a clear "good" way to even define equality.

Post by 'David "Morgan" Morgan' via Dart Misc
Subclassing doesn't make sense for value types: there's no way to

implement "equals" properly.
I don't understand that. What is the challenge with "equals"?
Why can't you do
class B extends A {
final String x;
bool operator==(other) => other is B && super.==(other) && other.x == x;
}
I admit I have never done that but always assume I could
--
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

['Alan Knight' via Dart Misc]

Does that apply more to value objects than to regular ones? It seems like
it's a general property of subclassing and the way equality is defined in
Dart.


On Mon, Oct 12, 2015 at 2:27 PM 'David "Morgan" Morgan' via Dart Misc <

Post by 'David "Morgan" Morgan' via Dart Misc
The problem is that "b == a" and "a == b" will give you different answers.
Not cool at all ;)
https://www.google.com/#q=double%20dispatch%20for%20subclass%20equals
...but there's still the question of what you actually want to happen,
there isn't a clear "good" way to even define equality.

Post by 'David "Morgan" Morgan' via Dart Misc
Subclassing doesn't make sense for value types: there's no way to

implement "equals" properly.
I don't understand that. What is the challenge with "equals"?
Why can't you do
class B extends A {
final String x;
bool operator==(other) => other is B && super.==(other) && other.x == x;
}
I admit I have never done that but always assume I could
--
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

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

It's a general problem with subclassing and equality, nothing Dart specific.

You can't have both "nice" equality and subclassing. For value types people
care a lot about equality, so it's common to completely prohibit
subclassing. If you don't need equality to actually make sense, it can
still apply with subclassing :) ... i.e. if you have a specific use case
for it. But, it's likely to lead to surprises.

Post by 'Alan Knight' via Dart Misc
Does that apply more to value objects than to regular ones? It seems like
it's a general property of subclassing and the way equality is defined in
Dart.
On Mon, Oct 12, 2015 at 2:27 PM 'David "Morgan" Morgan' via Dart Misc <

Post by 'David "Morgan" Morgan' via Dart Misc
The problem is that "b == a" and "a == b" will give you different answers.
Not cool at all ;)
https://www.google.com/#q=double%20dispatch%20for%20subclass%20equals
...but there's still the question of what you actually want to happen,
there isn't a clear "good" way to even define equality.

Post by 'David "Morgan" Morgan' via Dart Misc
Subclassing doesn't make sense for value types: there's no way to

implement "equals" properly.
I don't understand that. What is the challenge with "equals"?
Why can't you do
class B extends A {
final String x;
bool operator==(other) => other is B && super.==(other) && other.x == x;
}
I admit I have never done that but always assume I could
--
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

--
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]

@David: doesn't this solve it:
class B extends A {
String x;

bool operator==(other) => this.runtimeType == other.runtimeType &&
super==(other) && other.x == x;
}
(Assuming that definition of == is copied to every class)

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

Yes, that also makes it symmetrical, but it's not particularly satisfactory.

If all you know about is A I can give you a B that looks like a broken A,
because it will never compare equal to an A, even though as far as you can
tell it's identical.

I don't want to derail this thread further discussing subclassing and
equality, it's an old and well explored topic. The bottom line is, there's
no happy way to do it :)

https://www.google.com/webhp?#q=subclassing%20and%20equality

Post by Anders Holmgren
class B extends A {
String x;
bool operator==(other) => this.runtimeType == other.runtimeType &&
super==(other) && other.x == x;
}
(Assuming that definition of == is copied to every class)
--
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]

Ah yeah I forgot about that. Hit that many times over the years in Java but not recently enough to remember ;-)

From memory I've used variants of the approach described in "The canEqual method" of https://www.artima.com/lejava/articles/equality.html

I think we should be wary in putting too many restrictions on value objects or they will end up as dumbed down as enums and consequently not usable by anyone other than Don Olmstead ;-)

Value objects are often used for domain models and domain models is not an area I believe we should consider giving up inheritance.

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

Having seen both sides, domain models that allow inheritance and domain
models that prohibit it, I am enthusiastically in support of banning
inheritance ;) ... as it leads to a lot of trouble, where mixins and
interfaces get you all the expressive power you need with none of the
problems.

Completely apart from issues with equality, using inheritance in a
single-inheritance language means you have to pick just one base class,
where domain models don't naturally have that restriction. That tends to
lead to a design that's largely driven by the use of inheritance rather
than the domain itself.

Interfaces and mixins free you to build something that actually models the
domain.

Post by Anders Holmgren
Ah yeah I forgot about that. Hit that many times over the years in Java
but not recently enough to remember ;-)
From memory I've used variants of the approach described in "The canEqual
method" of https://www.artima.com/lejava/articles/equality.html
I think we should be wary in putting too many restrictions on value
objects or they will end up as dumbed down as enums and consequently not
usable by anyone other than Don Olmstead ;-)
Value objects are often used for domain models and domain models is not an
area I believe we should consider giving up inheritance.
--
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]

Completely apart from issues with equality, using inheritance in a single-inheritance language means you have to pick just one base class, where domain models don't naturally have that restriction

Yes that is true, in a pure (non implementation) sense domain models naturally use multiple inheritance, bidirectional relationships etc. When implementing one in code you obviously need to make tradeoffs.

I agree what is really important from the modelling point of view is the relationships which can be captured via interfaces and associations / references.

When implementing the details, mixins can do all you need and are more flexible that implementation inheritance.

That said though I wouldn't agree that we should enforce that you can't inherit implementation from parent classes. In many cases a single parent is all you need so enforcing interface + mixin isn't ideal in that case IMO.

Maybe a restriction that parent classes must be abstract may make some sense, although not 100% for that either ;-)

[Don Olmstead]

Christ am I surrounded by Java devs? They don't need inheritance they don't
need whatever other nonsense Java came up with. The only thing enums are
lacking is flags. After that they are the same perfection found in C#. You
know the language that's Java done right.

:troll: for anders

[Lingfeng Xu]

I'm trying to think about the root of issue. So value classes are really
json (or generally data objects) schemata built in the language. This is
somewhat true for all the class based languages we have. A large part of
the need may be just data validation. Maps are too weak. Classes are too
clunky. This seems to be one of the issues, that Dart trying to solve,
by introducing optional typing. For primitives the fix is easy. "var" and
"int" works pretty well, since they are exchangeable. But classes and data
objects aren't exchangeable, yet. So it feels there is some ... something
missing, between the class-based idiom seen in static languages, and the
object-based (or say map-based) idiom seen in dynamic languages.

圚 2015幎10月9日星期五 UTC-7䞊午10:48:36Bob写道

Post by 'Bob Nystrom' via Dart Misc
Here's my notes!
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-30%20DEP%20Committee%20Meeting.md
This is from *last* week's meeting. Sorry for the delay. There was no DEP
meeting this week.
Cheers!
– bob

[kc]

Post by Lingfeng Xu
I'm trying to think about the root of issue. So value classes are really
json (or generally data objects) schemata built in the language. This is
somewhat true for all the class based languages we have. A large part of
the need may be just data validation. Maps are too weak. Classes are too
clunky. This seems to be one of the issues, that Dart trying to solve,
by introducing optional typing. For primitives the fix is easy. "var" and
"int" works pretty well, since they are exchangeable. But classes and data
objects aren't exchangeable, yet. So it feels there is some ... something
missing, between the class-based idiom seen in static languages, and the
object-based (or say map-based) idiom seen in dynamic languages.

Some form of typed JSON which can express trees of value objects? Similar
to JavaFX, QML?

K.

['Brian Slesinsky' via Dart Misc]

Post by kc

Post by Lingfeng Xu
I'm trying to think about the root of issue. So value classes are really
json (or generally data objects) schemata built in the language. This is
somewhat true for all the class based languages we have. A large part of
the need may be just data validation. Maps are too weak. Classes are too
clunky. This seems to be one of the issues, that Dart trying to solve,
by introducing optional typing. For primitives the fix is easy. "var" and
"int" works pretty well, since they are exchangeable. But classes and data
objects aren't exchangeable, yet. So it feels there is some ... something
missing, between the class-based idiom seen in static languages, and the
object-based (or say map-based) idiom seen in dynamic languages.

Some form of typed JSON which can express trees of value objects? Similar
to JavaFX, QML?

I recommend studying the protobuf library to see what sort of problems such
a library needs to solve. An integer is not as simple as you think when
you're exchanging data between different languages. You need to say
something about the supported range.

If the other language you're talking to is JavaScript then 53-bit integers
is as good as you're going to do. [1] After that you need to switch to
string encoding or use doubles. If you're exchanging data with Java, Go, or
C++, you probably need to figure out how to represent 32-bit and 64-bit
integers.

- Brian

[1] http://www.2ality.com/2012/07/large-integers.html