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

[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

[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 other 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 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:

[Günter Zöchbauer]

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

On Saturday, October 10, 2015 at 11:29:52 PM UTC+2, Andreas Kirsch wrote:
> +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).

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

On Sunday, October 11, 2015 at 2:32:10 AM UTC+2, tatumizer-v0.2 wrote:
> 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)
>
>
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.

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

[kc]

On Monday, October 12, 2015 at 2:36:04 PM UTC+1, David Morgan ☯ wrote:

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.

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.

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

 

On Mon, Oct 12, 2015 at 1:34 PM tatumizer-v0.2 <tatu...@gmail.com> wrote:

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

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

[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