will Dart ever support javascript style object literals?

[Darren Cruse]

Was inspired by Lars Bak's talk at Strange Loop this past week to finally try out Dart for real this morning...

And as someone with one foot in the java world and the other in the javascript world I'm seeing a lot to like about Dart.

The optional types, the eclipse debugging and error highlighting, the multi-line strings with variable substitutions, the shorter syntax options for functions e.g. =>.

All really good stuff, and I was thinking/hoping maybe Dart would be the *single* magic language to bring together the java and javascript die-hards where I work.

But I was disappointed when I realized you can't really do javascript-style object literals and start that way as a stand-in for what you'd later "upgrade" to have a class definition.

I did search the group and I see this was discussed e,g, back in february

But I wanted to ask if there's any new developments one way or another regarding the likelihood of object literals being added and how soon.

e.g. Referring to this part of what Bob Nystrom posted:

You're right that anonymous types could be useful and would play well with the fact that Dart doesn't require type annotations for variables. We may add them at some point, but our goal isn't to have all possible features in 1.0. We want to focus on the core features that programmers really need and leave ourselves room to grow the language over time.

To be blunt, my gut feeling (regarding the reference above to the "features that programmers really need") is I think the hard core java guys will love the features Dart's providing, but the javascript guys will view object literals as a "feature they really need" i.e. so much they probably won't consider using Dart.

And maybe I'm biased in that my most recent project started as a java/spring/hibernate project but since it was so heavily focused around JSON RESTful services we started using server side javascript in what amounted to a "DSL" making JSON easier.  I mean truly for us the object literal syntax being inherently javascript was for us a killer feature.

My real question is will object literals be added in Dart or is it really technically and/or philosophically against the grain of Dart as a language such that it will likely never change.

[Ladislav Thon]

I think the most accurate answer (sadly) lies over here: http://dartbug.com/1089

LT

[Darren Cruse]

Thanks Ladislav so you're saying the "WontFix" status means no they won't be added.

But it's funny despite the title the comments in that issue didn't reflect very closely what I was thinking about.

And I was just thinking part of my expectations might have been influenced because I'd used groovy heavily a couple years ago and Perl long before that.

Groovy added dynamic language semantics on top of java by adding closures plus sticking what amounts to a map as a wrapper on the java object instances.

So Groovy winds up with the static semantics of java *augmented* by the dynamic "expando" semantics (which had reminded me of my Perl days which was my first exposure to the way these dynamic languages basically combine maps with first class functions to represent objects).

And groovy is also doing this optional types idea btw so that's the other similarity to Dart.

And groovy's claim to fame was that java programmers could basically start with java and it would mostly still work as groovy, then they could gradually add groovy-isms.  Where groovy does have basically this same object literal notion going on and you can even mock java objects/interfaces using those (which I'm guessing means in this case it's basically using the "map" so to speak but *without there being a real java instance behind it*).

Maybe I'd intuitively hoped/assumed that Dart was going to be similar.

i.e. The fact that Dart can convert and run as javascript I guess had me thinking that I'd still be able to do object literals and in line JSON objects just like I would in javascript.  So that Dart might have made a similar claim to javascript programmers that groovy made to java programmers - start with something basically javascript and add types to enhance it (it's funny groovy of course is the opposite you start with types in java and start removing them as the code becomes more concise and more dynamic whereas here you'd be adding types not removing them).

And broadly speaking I'd have imagined the implementation of groovy and Dart would have been similar but have started from different ends.  Whereas groovy added the map to augment the statically laid out java instances, I'd have thought standard javascript objects would have played the "map" role and Dart would have "augmented" those with a statically laid out structure used when people define real classes using Dart.

The point being that as with groovy the basic representation of the base Object for the language needs to have both the dynamic map-ish thing going on *and* the statically laid-out it's-all-known-at-compile time thing going on.

It seems like this is the Dart could wind up enhancing javascript's semantics not replacing it's semantics as I see here   

Leading to the giant love-fest of javascript and java programmers I'd originally envisioned. :) 

[Christoph Husse]

i.e. The fact that Dart can convert and run as javascript I guess had me thinking that I'd still be able to do object literals and in line JSON objects just like I would in javascript.  So that Dart might have made a similar claim to javascript programmers that groovy made to java programmers - start with something basically javascript and add types to enhance it (it's funny groovy of course is the opposite you start with types in java and start removing them as the code becomes more concise and more dynamic whereas here you'd be adding types not removing them).

The difference here is that Groovy had Java as a basis and started from there. Java is actually a good basis for a language, since it just lacks practically all important features one want to have in a language, but one, like Groovy did, can extend that to a language that is actually nice to use. With JavaScript this is differently. JavaScript is a horrible abomination of a language. Chose that as your basis and you won't get any better, only worse.

BTW, Dart can sure have JSON to object conversion in a later stage when it got advanced reflection and maybe dynamic code generation (the feature I hope for). I am not sure about object literals though.

 

Leading to the giant love-fest of javascript and java programmers I'd originally envisioned. :) 

Oh no ^^... Its a good thing that Dart steers away from the two languages I hate :D

[Ladislav Thon]

> i.e. The fact that Dart can convert and run as javascript I guess had me thinking that I'd still be able to do object literals and in line JSON objects just like I would in javascript.

You know, JSON is still a subset of Dart. And guess what, you can build a map-as-object facility in Dart yourself. But I personally think it isn't worth it (even if it would be like 10 or 20 lines of code).

LT

[Darren Cruse]

With JavaScript this is differently. JavaScript is a horrible abomination of a language. Chose that as your basis and you won't get any better, only worse.

 

I've always enjoyed learning different programming languages and whatever flaws javascript might have, I don't think this "unification" of maps and objects is one of them.  I feel that idea (together with first class functions) is the essence of what's good - even elegant - in javascript.  It's something like the "code is data" idea of LISP, but using maps rather than lists.

So this for example is why JSON just "falls out" of javascript as a simple subset of the language - code is data and JSON is just data i.e. javascript without any functions ("code") in it's values.

Note that a javascript programmer doesn't even think in terms of Map or HashMap or stuff like that.  Nor "reflection" for that matter.

Yet all the power of those things is there in the language just without all the fancy-pants language and complexity.

So I don't see javascript as an abomination I see it as one of these beautiful "little languages" (I'm thinking back to FORTH now), that has some rough edges but has an elegance that a language like java really doesn't.

(if any of this sounds alien or unbelievable to you I refer you to the bible of one Mr Douglas Crockford :)

[Darren Cruse]

re:

You know, JSON is still a subset of Dart. And guess what, you can build a map-as-object facility in Dart yourself. But I personally think it isn't worth it (even if it would be like 10 or 20 lines of code).

and 

BTW, Dart can sure have JSON to object conversion in a later stage when it got advanced reflection and maybe dynamic code generation (the feature I hope for). I am not sure about object literals though.

Yeah I played a little with JsonObject and it seems to solve what to me is the main issue simply that Dart dropped support for using the dot notation for  accessing the values in Maps.

Which of course breaks the ability to substitute a map for an object.

Even when I was doing groovy this was wonderful for mocking objects when testing.

And as I said my current project is *all* about JSON RESTful services.  For me having to always declare and parse JSON as a string rather than just in -line in the code would feel a step backwards.

So I do see these things as important, but the more I read about Dart the more I'm feeling the language designers (the Dart community as a whole?) are coming more from the static programming language tradition.  i.e. that being able to know things at compile time, and being able to improve performance using simple offsets to fields in a pre-defined object layout, is felt to be more valuable than dynamic run time stuff afforded by using maps as objects.

That basically Dart is coming more from the point of view of what it would be like for Java/C# style language to run in the browser.  And that the optional types are only for when you declare variables referring to objects not when you declare objects themselves.  

In a way I'm fine with that I just didn't get that in the beginning I wish this was stated more clearly e.g. on dartlang.org or something.

e.g. If Dart were presented/described as "GWT++" or something and had actually just used an enhanced java syntax directly I might have started with different expectations.

I'll still consider using Dart (e.g. if they get some "location transparency" going with local/remote isolates feeling like a simpler erlang I think that could be really exciting).  

But anyway yeah I'm sure it wouldn't be hard to add what JsonObject does to Dart's default Map.

But maybe that's not the direction the language designers want to take.

But to make trouble, I wonder am I allowed to suggest this as an enhancement in that Dart issues list?  :)

(I notice I can click the New Issue but the dropdown implies it's really for submitting defects I don't see a choice for "Enhancement") 

[Ladislav Thon]

> Which of course breaks the ability to substitute a map for an object.
>
> Even when I was doing groovy this was wonderful for mocking objects when testing.

I'd say that Dart has you covered here. You can mock simply by passing arbitrary objects, they only have to have the needed methods. And if you want to have some static typing here, you can implement the mocked class's interface. It isn't that convenient, but it isn't that bad either.

> And as I said my current project is *all* about JSON RESTful services.  For me having to always declare and parse JSON as a string rather than just in -line in the code would feel a step backwards.

You can still use Dart in a JavaScripty way -- just Maps and Lists, then you have the same Json.parse/stringify. You gain something, and you lose something else.

In the future, I expect some sophisticated JSON/objects mappers, but we are not there yet. Note that Dart isn't finished, especially the libraries will get a lot of love after M1 is out.

> So I do see these things as important, but the more I read about Dart the more I'm feeling the language designers (the Dart community as a whole?) are coming more from the static programming language tradition.

Not really. All the Dart Masters (Lars, Kasper and Gilad) have strong SmallTalk background and Dart is fundamentally dynamically typed. You're right that there is no "free love" in Dart unlike JavaScript, it really has more of a static structure. It has reason, though: Dart is designed to be performant (in not so distant future, Dart should be significantly faster than JavaScript) and toolable (I'd say that Dart IDEs are already way better than IDEs for JavaScript).

> But anyway yeah I'm sure it wouldn't be hard to add what JsonObject does to Dart's default Map.
>
> But maybe that's not the direction the language designers want to take.

That's probably correct. Dart is all about _structure_, which is something that JavaScript severely lacks.

> But to make trouble, I wonder am I allowed to suggest this as an enhancement in that Dart issues list?  :)
>
> (I notice I can click the New Issue but the dropdown implies it's really for submitting defects I don't see a choice for "Enhancement") 

Sure you are allowed! Just delete all the text that the defect template suggests and go ahead!

LT

[Darren Cruse]

On Sunday, September 30, 2012 8:00:46 AM UTC-5, Ladislav Thon wrote:

> Which of course breaks the ability to substitute a map for an object.
>
> Even when I was doing groovy this was wonderful for mocking objects when testing.

I'd say that Dart has you covered here. You can mock simply by passing arbitrary objects, they only have to have the needed methods. And if you want to have some static typing here, you can implement the mocked class's interface. It isn't that convenient, but it isn't that bad either.

Just FWIW the code below demonstrates what Ladislav said about mocking with classes being fine (just disable checked mode when you run), and also what I was saying about mocking with Maps being close but no cigar (actually with JsonObject there might just be a bug or a tweak needed to work when closures are in the Map I didn't try and debug it).
  

#import("package:JsonObject/JsonObject.dart");

class RealGuy {
  String name;
  int age;
  RealGuy(this.name, this.age);
  void incrementAge() { age++; }
}

class MockGuy {
  String name = "fake";
  int age = 25;
  MockGuy(name, age);
  void incrementAge() { age++; }  
}

void happyBirthday(RealGuy g) {
  // the dots below are a problem if g is a Map not JsonObject:
  g.incrementAge();
  print("${g.name} had a birthday: ${g.age} years old");
}

void main() {
  RealGuy g = new RealGuy("derek", 42);
  happyBirthday(g);
 
  MockGuy m = new MockGuy("",0);
  happyBirthday(m);  

  // dot notation will fail without JsonObject
  // but JsonObject blows up if a closure is in the Map  
  var mockMap = new JsonObject.fromMap({
    "name": "map",
    "age": 26,
    "incrementAge": () { /* also can't do e.g.: this["age"]++;*/ }
  });  
  happyBirthday(mockMap);    
}
 

Not really. All the Dart Masters (Lars, Kasper and Gilad) have strong SmallTalk background and Dart is fundamentally dynamically typed. You're right that there is no "free love" in Dart unlike JavaScript, it really has more of a static structure. It has reason, though: Dart is designed to be performant (in not so distant future, Dart should be significantly faster than JavaScript) and toolable (I'd say that Dart IDEs are already way better than IDEs for JavaScript).

What I feel after reading more and playing with Dart more is that Dart is dynamically typed but it doesn't qualify as a Dynamic Programming Language in the way described if you follow that link (on wikipedia which describes it the way I'd more or less come to think of it).

And any arguments over semantics aside, if somebody asks me I would tell someone starting with Dart that they should expect to think more like java, to start by defining their classes and interfaces and that's the expectation in Dart.

i.e. To convey this idea that in Dart types are optional for variable declarations but *types are not optional* in the sense that you need to define types (i.e. classes) for any/every object you're dealing with.

Which as I said for me means Dart is far closer to Java or C# than javascript.

And as I said for me personally that's no all bad, but it's certainly not all good.

Some of what's good about javascript (being able to do quick prototyping or simple things with less code and less "structure") has been lost in the pursuit of performance and IDE support.

But that's fine. :)

(despite how I sound I'm not hating Dart - I just realized anybody reading all this stuff I've written will probably want to strangle me :)

[Ladislav Thon]

What I feel after reading more and playing with Dart more is that Dart is dynamically typed but it doesn't qualify as a Dynamic Programming Language in the way described if you follow that link (on wikipedia which describes it the way I'd more or less come to think of it).

That is essentially right, Dart expects that by default you will want to have the program structured statically. But should you want some dynamic features like runtime code generation or modification, that should be supported too (in the future, not right now). But you will have to be very explicit about it.

 

And any arguments over semantics aside, if somebody asks me I would tell someone starting with Dart that they should expect to think more like java, to start by defining their classes and interfaces and that's the expectation in Dart.

i.e. To convey this idea that in Dart types are optional for variable declarations but *types are not optional* in the sense that you need to define types (i.e. classes) for any/every object you're dealing with.

To be honest, this is the way JavaScript is used today as well. If you look at modern JavaScript frameworks, all of them have a notion of classes and are built on top of them. Dart just puts them into the language.

 

Which as I said for me means Dart is far closer to Java or C# than javascript.

Yeah. I still think that Dart is "JavaScript for Java programmers" -- but from what I've heard, a lot of JavaScript people want more of static typing or actually static structure. This essentially boils down to the fundamental truth -- Dart doesn't want to replace JavaScript. Dart believes that there is a niche it can fulfill. If you are happy with JavaScript -- that's great, you should definitely continue to use it. If you find that Dart is more suitable for certain projects, that's great too and you are very welcome in this community.

LT

P.S.: if it looks like I want to convince you that Dart is the best language out there, then I do apologize -- but I really believe that that is the case :-)

[Darren Cruse]

FWIW on this project I was talking about we are using Ringo (which is Rhino with extensions to support the CommonJS module system along with a bunch of CommonJS modules).  This is in combination with Java/Spring/Hibernate.

So in some ways it provided us the combination of java classes and javascript looseness I was referring to.  Just in using two languages not one. :)  But obviously the java side doesn't apply in the browser of course...

And I can't claim that we are perfect or that I've given a ton of thought as to why, but we didn't wind up doing a lot of prototypes/classes in our javascript.

Maybe the fact that we were also using java is part of the answer.  Obviously we do have java objects mapping to the database with hibernate.

But truly the essence of a lot of what we are doing involves RESTful JSON requests coming in (where we use JSON Schema to define their structure not javascript prototypes/classes).  Then some manipulation/transformation of the JSON, and persistence of that into what really could have been something like Mongo (but for historical reasons we're using blobs in oracle).

The truth is in our server-side javascript, I think we were influenced by what we saw of CommonJS in Ringo, where CommonJS you know is not fundamentally object oriented it's really a way to package and namespace groupings of javascript functions.

So really the essence of our system surrounds functions manipulating and persisting/retrieving JSON.

So I don't see it as fundamentally object oriented in the classical (no pun intended) sense.

And I think the reason traces back to the JSON RESTful services, which I think also relates to the rise of these schema-less NoSQL databases that are so good at storing "semi-structured" data.

Which is to say I think today a lot of these modern service oriented systems would fall into this category.

Which is not to say I disagree with you completely - I thought of for example like Sencha when you said modern javascript frameworks define classes.  Which in that example maybe makes sense cause it's natural to model UI stuff with classes/objects.

But like I said Ringo doesn't do a ton of that - it's more about the CommonJS packages (which is also true with node.js I'm told).  And the JSGI standard it uses for handling http requests in javascript doesn't do so in terms of classes.

And when I consider the recent emphasis on functional programming, the rise in popularity in Clojure - to me these are all signs that classical object orientation is being questioned in a lot of ways nowadays.

i.e. I'm not sure that I'd agree with your comment about javascript developers begging for more use of classes and object orientation.

And yet I realize I've been polarized in my responses to your comments:  I *do* have doubts in the long run if really big javascript systems are going to be hard to understand and maintain.  Esp. if types have not been used well.  Yet I kind of feel like Jsdocs and careful naming of modules and functions may be enough at least in cases like ours on my project.

I've beat this to death but one last thing I'd like to share is this article by Erik Meijer which seems to speak to the essence of our conversation and the thing that I was thinking but didn't state.   Which is that ideally what I really want is kind of dial to turn up the typing or back the typing according to my needs, and for me I think the anonymous classes/object literal idea in Dart would be the ideal way to provide that - more than what I see in Dart right now:

Static Typing Where Possible, Dynamic Typing When Needed: The End of the Cold War Between Programming Languages

[Ladislav Thon]

And I think the reason traces back to the JSON RESTful services, which I think also relates to the rise of these schema-less NoSQL databases that are so good at storing "semi-structured" data.

Which is to say I think today a lot of these modern service oriented systems would fall into this category.

Yeah, I feel the pain. I still think that modern programming languages are not giving us proper tools for working with data, especially nowadays when data are commonly nested, highly dynamic and heterogenous. Maybe for you, JavaScript is working great (and that's cool!), but I personally don't see it as The Ultimate Answer. I don't know how The Answer will look like, though :-)

LT

P.S.: thanks for the link to the article. Didn't read it through yet, but I sense from the title that the authors are speaking from the perspective of statical typing camp that recently adopted some dynamic typing... which coincidentally seems to be the case in C# 4 :-)