Notes from 9/30 DEP meeting

[Bob Nystrom]

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. 

--
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 email to misc+uns...@dartlang.org.

[Brian Slesinsky]

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

--
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 email to core-dev+u...@dartlang.org.

[Bob Nystrom]

On Fri, Oct 9, 2015 at 11:44 AM, Brian Slesinsky <skyb...@google.com> wrote:

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.

 

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

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

On Fri, Oct 9, 2015 at 12:18 PM, Bob Nystrom <rnys...@google.com> wrote:

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]

On Fri, Oct 9, 2015 at 12:53 PM, Brian Slesinsky <skyb...@google.com> wrote:

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 data objects)

K.

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

[kc]

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

K.

On Friday, October 9, 2015 at 6:48:36 PM UTC+1, Bob wrote:

[Andreas Kirsch]

+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).

On Sat, Oct 10, 2015 at 4:07 PM, kc <kevin...@gmail.com> wrote:

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

--

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 email to misc+uns...@dartlang.org.

--

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.

[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

[Günter Zöchbauer]

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.

[Anders Holmgren]

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

[kc]

On Sunday, October 11, 2015 at 6:08:01 AM UTC+1, David Morgan ☯ wrote:

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.

 

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');

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

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

 // immutable

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]

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.

.

[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写道：

[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" }

}

On Mon, Oct 12, 2015 at 9:48 AM tatumizer-v0.2 <tatu...@gmail.com> wrote:

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 email to misc+uns...@dartlang.org.

--

Daniel Joyce

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

[David "Morgan" Morgan]

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.

[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

--
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 email to misc+uns...@dartlang.org.

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

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

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.

[Alan Knight]

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.

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

[David "Morgan" Morgan]

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.

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

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

[kc]

On Monday, October 12, 2015 at 9:45:48 PM UTC+1, Lingfeng Xu wrote:

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. 

[kc]

On Monday, October 12, 2015 at 9:45:01 PM UTC+1, Daniel Joyce wrote:

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.

 

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. 

[Brian Slesinsky]

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

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

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.

[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