Again, optionally remove the new keyword + Union types + Primary constructor.

[Cristian Garcia]

I was looking into some Elixir videos and saw a Ceylon hangout video, got me curious because I'd heard Ceylon was very close to Dart.

I poked around Ceylon's page and decided to code a simple class on their online editor, here is what I coded.

class Person (name, age) {

    variable String name;

    variable Integer | String age;

    

    shared String toString => "Name ``name``, Age ``age``";

}

Person person1 = Person ("Cristian", 26);

Person person2 = Person ("Mike", "Twenty three");

print (person1.toString);

print (person2.toString);

The other day Bob mentioned how maybe Dart should become more attractive by standing out of the crowd by adding "cool" features at the risk of being less familiar. Id like Dart to have these two features with are not really wild changes, already exist in other languages, and should be the future.

1. Optionally remove the "new" keyword. Because we don't care about memory allocation in Dart, period. It does nothing and factory constructors might not even create "new" objects so the word is in fact lying.
2. Union types. Because while we could use "dynamic" and check for all the cases ourselves, we also like type safety in Dart. Plus they are really cool and play well with the Non-null proposal. In fact, in Ceylon types cannot be null unless they are declared as SomeType? or SomeType| Null.
3. Primary constructor. Because record-like structures are "à la mode" because of FP, but in reality they are pretty useful for classes with few code. Might avoid the need to define a constructor at all.
   
   

Id like to write this code in Dart like this someday.

class Person (this.name, this.age) {

    String name;

    Integer | String age;

    

   String toString () => "Name $name, Age $age";

}

var person1 = Person ("Cristian", 26);

var person2 = Person ("Mike", "Twenty three");

print (person1);

print (person2);

Looks sexy doesn't it? And the changes are minimal.

[Cristian Garcia]

Primary constructors are also in c#6 by the way.

[Felipe]

I really like the idea of removing the "new" keyword, I think it is not a new issue in the Dart community. If I remember correctly it was not made by a historical reason.

I also find it very useful to have "Primary constructors".

I will not comment on the "union types" because I'm not sure.

[Benjamin Strauß]

Why not drop constructors completely and use factory methods on meta classes. With a primary factory method just like you said. The new keyword could also be dropped.

Now we would only need inner classes and first class modules being top level classes and we would be a bit closer to Newspeak. ;)

At this point i would take the risk. I think the userbase is still small enough (no offense) to take such breaking changes.

[Anders Holmgren]

A bit tangential but I reckon having age as a union type on the property is a bad idea. OK on the constructor arg but from there I'd always store it as an int in the property.

Otherwise all your code needs to deal with it possibly being a string or int

[Cristian Garcia]

Anders, I just wanted to use a union type in Ceylon and "got creative" ;)

On Sat, Aug 22, 2015, 19:07 Anders Holmgren <andersm...@gmail.com> wrote:

A bit tangential but I reckon having age as a union type on the property is a bad idea. OK on the constructor arg but from there I'd always store it as an int in the property.

Otherwise all your code needs to deal with it possibly being a string or int

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

[Yissachar Radcliffe]

The sooner union types get here, the better.

I think removing new makes more sense when it is mandatory and not optional. Otherwise we will see a mix of code that uses new and some that doesn't use new. And it is too late to remove the new keyword completely.

Not sure how I feel about primary constructors. When thinking about the case of multiple constructors they don't feel quite so elegant.

[Cristian Garcia]

Totally removing new is too much, it would make current code useless. The code proposed here contains no breaking changes.

Primary constructors are like a default constructor but every other (named) constructor needs to call the primary constructor because its inputs can be used to initialize final variables (I didn't de a good job showing this).

[Bob Nystrom]

So many language features in one email thread! :)

For now, I'll just talk about getting rid of new. We've talked a lot about union types before and there's another thread about it going on. Primary constructors are interesting too, but personally I don't find them super compelling.

First of all, there's no technical reason that Dart has a new keyword that I know of. Removing it would not cause ambiguities, and it does not have any real semantics that cannot be expressed some other way.

(Note, of course, that constructors are special. They are the only way to create a new instance of a class. You would still need to be able to define constructors. What we're talking about is the new keyword at the point that a constructor is invoked.)

Like others note, because Dart has factory constructors, seeing a new at a callsite doesn't actually tell you anything precise. It's more or less just a naming convention. Dart has it because it's makes the code a bit more familiar to users coming from other languages that use it. Of course, it makes it a bit less familiar to users coming from Python, Ruby, etc.

There are now and have always been people on the team who'd like to do away with new. I'm in the camp. My opinion was strengthened when I started looking at the example code from the Sky project:

class SkyHome extends App {

  Widget build() {

    return new Theme(

      data: new ThemeData(

        brightness: ThemeBrightness.light,

        primarySwatch: colors.Teal),

      child: new Title(

        title: 'Sky Demos',

        child: new Scaffold(

          toolbar: new ToolBar(center: new Text('Sky Demos')),

          body: new Material(

            type: MaterialType.canvas,

            child: new DemoList()))));

  }

}

With React-style rendering frameworks, a lot of code is constructing new lightweight objects. In code like the above, the new really does stand out as a pointless, heavy tax. It would read more like a DSL without them.

I could be wrong, but I do think we could remove new without making it a breaking change. We would just allow it to be omitted while still supporting it in old code that uses it. What we probably wouldn't be able to do is free up "new" to be usable as an identifier, but that's probably not a huge loss.

I agree with Benjamin that, semantically, you can think of a "new"-less constructor invocation as just a method call on the metaclass. We could do that even without supporting full metaclasses: just treat the unnamed constructor as a static call() method.

I don't know how the rest of the team feels about this, though. I'd be happy to see us get rid of new, but I don't know if I'd consider it my highest priority in terms of things I'd like to see changed in the language. If we're talking minor syntactic clean-ups, I'd rather get rid of semicolons or fix our broken type annotation syntax. The former gets us more in line with the aesthetics of more modern languages (Go, Scala, CoffeeScript, Python, Ruby, etc.) and the latter would solve real expressiveness problems in the language.

Cheers!

- bob

[Lasse R.H. Nielsen]

On Mon, Aug 24, 2015 at 10:09 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

So many language features in one email thread! :)

For now, I'll just talk about getting rid of new. We've talked a lot about union types before and there's another thread about it going on. Primary constructors are interesting too, but personally I don't find them super compelling.

First of all, there's no technical reason that Dart has a new keyword that I know of. Removing it would not cause ambiguities, and it does not have any real semantics that cannot be expressed some other way.

Nitpick, not technically true due to generics.

Look at:  f(foo < bar , baz > (qux * 2))

That's currently valid syntax for a call with two boolean values, but would also be syntax for calling the foo constructor with two type parameters.

At the syntax level, it is ambiguous. I'm sure we can find a way around that (probably just making it be the constructor call and requiring parentheses to distinguish the function call).

I'm completely for getting rid of 'new' :)

/L

--

Lasse R.H. Nielsen - l...@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 Berry]

Incidentally, the same ambiguity arises in the generic methods proposal, and there is some discussion there about what to do about the ambiguity.  Unfortunately I don't believe there's a way to do it without technically introducing backward incompatibilities, although I suspect in practice that the amount of code that would be broken by the change would be vanishingly small.  See https://github.com/leafpetersen/dep-generic-methods/blob/master/proposal.md#expressions for more discussion.

--

[Jan Mostert]

Why not have both styles?
new Object();
Object();

Then new becomes optional and the Java teams using Dart can continue using new for the sake of familiarity and at the same time you don't break older libraries using new.

[Benjamin Strauß]

Let's not forget that the meta classes proposal also introduces Object.new();. Whenever that will come.

[Rich Eakin]

On Mon, Aug 24, 2015 at 4:09 PM, 'Bob Nystrom' via Dart Misc <misc@dartlang.org> wrote:

There are now and have always been people on the team who'd like to do away with new. I'm in the camp. My opinion was strengthened when I started looking at the example code from the Sky project:

class SkyHome extends App {

  Widget build() {

    return new Theme(

      data: new ThemeData(

        brightness: ThemeBrightness.light,

        primarySwatch: colors.Teal),

      child: new Title(

        title: 'Sky Demos',

        child: new Scaffold(

          toolbar: new ToolBar(center: new Text('Sky Demos')),

          body: new Material(

            type: MaterialType.canvas,

            child: new DemoList()))));

  }

}

With React-style rendering frameworks, a lot of code is constructing new lightweight objects. In code like the above, the new really does stand out as a pointless, heavy tax. It would read more like a DSL without them.

I think this is a great example of how, if the new keyword were to be made optional, the syntax would be even more fluent (in the sense of so-called 'fluent interfaces', which is one of my favorite features of the dart language).

Lately I've been finding myself writing utility functions that handle the new internally and just return the object, as it makes the callsite more readable in what I've been working on. Lately this has been a physics sim where I don't want to see Vector3's being new'ed everywhere, I just want to use them and see the equations clearly.