final vs. let. Round 2.

[W. Brian Gourlie]

I prefer using single assignment variables when possible.  I find myself not doing this simply because littering the code with "final" looks much worse than "var."  Can we get a more terse single assignment keyword?

[Bob Nystrom]

On Fri, Mar 1, 2013 at 3:28 PM, W. Brian Gourlie <bgou...@gmail.com> wrote:

I prefer using single assignment variables when possible.  I find myself not doing this simply because littering the code with "final" looks much worse than "var."  Can we get a more terse single assignment keyword?

This was discussed a bunch early on when we released. My hunch is that it's too late at this point for the issue to be revisited but maybe someone on the language team will take an interest.

At my office we went back and forth on what style to use and eventually decided to not bother with final for local variables. It's a bit visually distracting and given that our methods are usually pretty short, it doesn't really help with maintainability that much. (We still like final for fields, though.)

Cheers!

- bob

[Gilad Bracha]

I believe final should be the default.  Like many things I believe, we don't see the world quite ready for that.  Likewise some new-fangled word instead of final ('val' anyone?). 

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

--
Cheers, Gilad

[Vijay Menon]

I do try to use 'final', but I agree it feels visually heavyweight.  I always liked the idea of 'val' since you mention it.  :-)

[Bob Nystrom]

On Fri, Mar 1, 2013 at 3:38 PM, Gilad Bracha <gbr...@google.com> wrote:

I believe final should be the default.  Like many things I believe, we don't see the world quite ready for that.  Likewise some new-fangled word instead of final ('val' anyone?). 

I would love "val" too. One of my favorite little things about Scala.

- bob

[W. Brian Gourlie]

I would be perfectly content with "val"

Hopefully it's not too late to sneak it in to replace final  :)

w.brian

[chl]

I agree with Gilad, that final should be the default.

[mythz]

Other than 'val', you could use potentially declare 'let' for an immutable binding. 

Not sure if it's a good thing to overload the 'let' keyword which will be familiar to JS devs with EcmaScript 6 'let' for defining block scoped variables.

Looking at what others are doing there was a C# proposal for using a '!' suffix:

http://twistedoakstudios.com/blog/Post330_non-nullable-types-vs-c-fixing-the-billion-dollar-mistake

This is good because it will also allow you add annotations to types with 1 char suffix operator, e.g:

int! a = 10; 

vs

val a = 10; //gives the appearance it's tools won't infer it as an int

val int a = 10; // just looks odd.

For completeness C# uses '?' suffix to define nullable value types, e.g:

int? a = 10; //Nullable int

The annotations for the closure compiler use the '!' as a prefix:

https://developers.google.com/closure/compiler/docs/js-for-compiler

{!int}; //non-null

{?number}; //A number or null.

Whilst it should be the default, I don't think it will have wide appeal as I suspect most devs think immutability is reserved for esoteric functional languages.

[Alex Tatumizer]

int☂ a = 10; // non-nullable

int☠ a; // nullable

Killer feature.

[Rick Hightower]

How about val for implicit types and final for explicit types... so you have

int a = 1;

var a = 1;

They are roughly equivalent.

Now you would have:

final int a = 1;

val a = 1;

They are roughly equivalent.

 val / var dynamic or implicit types

[George Moschovitis]

I believe final should be the default.  Like many things I believe, we don't see the world quite ready for that.  Likewise some new-fangled word instead of final ('val' anyone?). 

+1000

 final by default would be great!

alternatively using 'let' instead of 'final' would be an improvement.

-g.


 

[Dirk Detering]

Depends on what you mean by "killer".
You proposed some weird characters in other threads too.
Due to the fact that my Android phone does not display those characters (they are all shown as rectangle), this indeed "killed" the code you show.

Back to topic: I am absolutely for default final, resp. "val". I am used to it from Scala too. But I always wished Scala had chosen 'let' instead of val, because on one hand it reads better in a mathematical sense ("let a be the result of ...") and is better distinguished from 'var' at a glance.

So if EcmaScript 6 let keyword semantics is not an argument to stay away from using 'let' in Dart, I would prefer that one.

KR
Det

[Aza Tek]

final can be replaced with fix,
to indicated that the binding is fixed.

[Baldo Davide]

On Sat, Mar 2, 2013 at 12:38 AM, Gilad Bracha <gbr...@google.com> wrote:
> I believe final should be the default.

+1
It would really help, can't we add an option to implicitly declare
everything final?

--
Regards,
Davide Baldo

[Dirk Detering]

Am 02.03.2013 09:13 schrieb "Aza Tek" <aza...@gmail.com>:
>
> final can be replaced with fix,
> to indicated that the binding is fixed.

That would afaic intoduce a completely new terminus, never seen elsewhere before, while 'final' is already a known keyword from Java, 'val' a known keyword from Scala, Kotlin and ML, 'let' a known keyword from different languages including Roy, EcmaScript 6, Haskell, ML again - although with different semantics in each.

I would still prefer 'let' over 'val', assuming Dart will never have a 'let .... in ....' construct.

[Aza Tek]

On Sat, Mar 2, 2013 at 12:03 PM, Dirk Detering <mail...@googlemail.com> wrote:

> final can be replaced with fix,

> to indicate that the binding is fixed.

That would afaic intoduce a completely new terminus, never seen elsewhere before, 

Sometimes that's good thing. All these others are overloaded and can lead to confuse. 

Also 'fix' for 'fixed' has an element of 'self-explanatory', and is less likely to be confused with immutability.

[George Moschovitis]

I believe final should be the default.  Like many things I believe, we don't see the world quite ready for that.

Maybe you should fight harder for your beliefs. I mean, a renowned language researcher has an 'obligation' to educate the world.

-g.

[Thomas Schranz]

+1 for final as default :)

also 'let' instead of 'final' would make sense regarding the arguments from above (easy to visually distinguish from 'var' & feels more lightweight than final).

[Alex Tatumizer]

>  this indeed "killed" the code you show.

For systems without Unicode support, different suffix

int$1B a; // nullable, billion-dollar mistake

[Ladislav Thon]

I believe final should be the default.

+1.

 

 Like many things I believe, we don't see the world quite ready for that.

+1.

 

 Likewise some new-fangled word instead of final ('val' anyone?). 

I have never liked val, as it's too similar to var. Which, for someone, is an advantage instead of disadvantage. I'd personally prefer def.

LT

[Michael Hendricks]

On Sat, Mar 2, 2013 at 2:31 AM, Baldo Davide <bald...@gmail.com> wrote:

On Sat, Mar 2, 2013 at 12:38 AM, Gilad Bracha <gbr...@google.com> wrote:
> I believe final should be the default.

It would really help, can't we add an option to implicitly declare
everything final?

I made a similar proposal 16 months ago: https://code.google.com/p/dart/issues/detail?id=252  The Dart team concluded that it was a good idea but "not worth rocking the boat"

I think it's helpful to remember that Dart is a conservative language.  I think Lars called it "boring" in a recent conference talk.  The Dart team feels they can afford a limited innovation budget and they've already spent it on optional types and isolates.  I don't intend that as a criticism.

-- 

Michael

[Alex Tatumizer]

@Dirk:

by "killer feature" I really meant "the feature that kills the language".

I think dart has budget for one extra operator - umbrella (that is umbrella(x)=(x==null?antinull:x). It will greatly simplify dealing with nulls. Finding a good syntax for it is not easy, because every "good" symbol is already in use.

I consider talks about billion-dollar bugs a distraction. 99+% of bugs come from perfectly initialized variables - so what, we declare initialized vars evil, too?

If you want to be more pious than the Pope, maybe switching to Ada would be a good idea? 

[Dirk Detering]

2013/3/2 Ladislav Thon <lad...@gmail.com>

 

 Likewise some new-fangled word instead of final ('val' anyone?). 

I have never liked val, as it's too similar to var. Which, for someone, is an advantage instead of disadvantage. I'd personally prefer def.

 

I would vote against def, because
a)  in Groovy def is used to define variables and methods/functions alike,and is only used to omit the return type (somehow like var in Dart currently). It has nothing to do with readonly access.

b) in Scala def is used to define particularly methods/functions, or better "values that are recalculated on each access". So they are indeed not "reassignable", but have a totally different semantic to val, which also exists. There is a concept around def vs. val, saying that you can replace val with a parameterless def and vice versa without changing the caller.

But from an implementor's view the effect is different.

c) Python uses the def keyword explicitly to define functions.

d) Ruby uses the def keyword explicitly to define methods.

So far, def is the second worst keyword to use here, after final, imho.

Det

[Alex Tatumizer]

There's one symbol never used in dart: backtick `
it may mean "final" when precedes a name:

int `a=0; // not an eyesore like other variants, character ` is barely visible. 

[Ladislav Thon]

I have never liked val, as it's too similar to var. Which, for someone, is an advantage instead of disadvantage. I'd personally prefer def.

 

I would vote against def, because
a)  in Groovy def is used to define variables and methods/functions alike,and is only used to omit the return type (somehow like var in Dart currently). It has nothing to do with readonly access.

b) in Scala def is used to define particularly methods/functions, or better "values that are recalculated on each access". So they are indeed not "reassignable", but have a totally different semantic to val, which also exists. There is a concept around def vs. val, saying that you can replace val with a parameterless def and vice versa without changing the caller.

But from an implementor's view the effect is different.

c) Python uses the def keyword explicitly to define functions.

d) Ruby uses the def keyword explicitly to define methods.

So far, def is the second worst keyword to use here, after final, imho.

You can always find counterexamples. For example, EcmaScript 6 uses let as a sort of replacement of var, fixing the scoping rules. So let is a no go.

LT

[Dirk Detering]

2013/3/2 Ladislav Thon <lad...@gmail.com>

You can always find counterexamples.

So true....

 

For example, EcmaScript 6 uses let as a sort of replacement of var, fixing the scoping rules.

I know, we mentioned that before in this debate. 

 

So let is a no go.

I wouldn't necessarily say that.

At least this let semantically assigns names to values, not behaviour (method, named function) like def does.

Again, I prefer let  mostly because it makes a nice mathematical story (comparable to given). Otherwise val would be the way to go. One gets very used to it, even beside var as Scala proofs. 

 

LT

[Alex Tatumizer]

Guys, you are so picky, it's impossible to please you...

Umbrella is bad: kills somebody's Android

Skull is bad: too scary

What's wrong with backtick people?

It's an ASCII symbol, supported by every font.

Any reason for not liking it?

[Matthew Butler]

Please not the backtick, I come from ruby and perl, backtick is to execute shell command.

[Alex Tatumizer]

Perl has other operators not compatible with dart:

() The null list, used to initialize an array to null.

.. The range operator, which is really two different operators depending on the context. tl;dr...

Speaking of backticks: they come from sh. Is it a goal of dart to be compatible with sh? Very tall order.

[Baldo Davide]

can't we just add an option with a file scope?
something like

!use final-default

at the beginning of a .dart file?
is considered THAT bad adding options?

>
> --
> Consider asking HOWTO questions at Stack Overflow:
> http://stackoverflow.com/tags/dart
>
>

--
Regards,
Davide Baldo

[Paul Brauner]

I couldn't read the whole thread but like Gilad I think that final should be the default and I would be glad with val but I'm fine with final. I don't care it's more verbose, I use final everywhere in my code. It's just too bad that it adds one word when you explicitly type some variable, I wish it was the other way around (i.e. that you would need one more word to indicated that an explicitly typed variable is re-assignable).

Paul

[geevi]

Hi,

It would be great if final was default. But now that would involve breaking all dart code out there. There is an alternative that was proposed [https://groups.google.com/a/dartlang.org/forum/?fromgroups=#!topic/misc/oILnLwb5vMk]. That is use

  var x := 1; \\ or

  int x := 1;

for an immutable binding. This way all existing code continues to work, and final bindings can be created without much trouble.

I also wish libraries would just be classes with nested class definitions and the full power of extent, extend with, and implements. But thats for another thread. :-).

cheers,

girish

[Aza Tek]

+1

--

[W. Brian Gourlie]

That is use
  var x := 1; \\ or
  int x := 1;

for an immutable binding. This way all existing code continues to work, and final bindings can be created without much trouble. 

I like this idea. 

[geevi]

Please star the bug [https://code.google.com/p/dart/issues/detail?id=8906], if you want this in. :-)

[mythz]

+1 great idea.

[Colm Sloan]

I'd also love final as default but I know it will never happen. I was wondering if the dart formatter could have an option to automatically replace var with final if it's applicable.

--

[Alex Tatumizer]

Just curious: if you make final a default, how would you declare non-final?

[Gilad Bracha]

On Mon, Mar 4, 2013 at 10:51 AM, Alex Tatumizer <tatu...@gmail.com> wrote:

Just curious: if you make final a default, how would you declare non-final?

That is one more reason we didn't go that way. You need a keyword that indicates that something is mutable. Hard to find something familiar/short/attractive.

mutable x;

x = 3;

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

--
Cheers, Gilad

[Alex Tatumizer]

>Hard to find something familiar/short/attractive

Backtick? :)
int `x;  // mutable;

foo(int `y, int z) { // y marked as mutable, z is not
}

Short? tick
Attractive: tick (at least, not ugly)
Familiar: not very much, but  looks cute, very easy to get used to.

There's a small problem with for loop though, where it should be mutable by default.

[George Moschovitis]

Just curious: if you make final a default, how would you declare non-final?

That is one more reason we didn't go that way. You need a keyword that indicates that something is mutable. Hard to find something familiar/short/attractive.

mutable x;

x = 3;

how about:

let x = 3; // immutable

int x = 3; // immutable

var x = 3; // mutable

var int x = 3; // mutable

-g.

[Matthew Butler]

On Monday, March 4, 2013 3:13:06 PM UTC-4, George Moschovitis wrote:

how about:

let x = 3; // immutable

Personally I'm not a fan of adding new keywords. 

 

int x = 3; // immutable

This would be a backwards incompatible change. And would stand to break a fair amount of code.

var x = 3; // mutable

var int x = 3; // mutable

The latter of which I'm not a fan of, too many key words to declare a statically checked variable. 

-g.

Personally I'm a fan of leaving existing syntax (so final keyword continues to exist or clearly visible) but using a :=  to make the variable immutable. At first I was on the fence about this because of its history with the Go programming language. But I don't think there is cause for much concern in their different usages. 

I notice in the other thread which was referenced that Gilad mentioned that a separate assignment operator wasn't an option? Was it because it is not a construct that is used in other languages and as such not something familiar to someone new to Dart who may see it used?

Matt

[Gilad Bracha]

On Mon, Mar 4, 2013 at 11:29 AM, Matthew Butler <butler....@gmail.com> wrote:

I notice in the other thread which was referenced that Gilad mentioned that a separate assignment operator wasn't an option? Was it because it is not a construct that is used in other languages and as such not something familiar to someone new to Dart who may see it used?

Pretty much. Which is also the problem with much of what has been proposed on this thread.  We've been through quite a few of these ourselves.  Dart fixes a lot of things that are a problem elsewhere. We can't fix too much, or we'll lose our audience.  Deciding where that line goes is something the Dart team struggles with continuously, but as time passes, our leeway shrinks. And of course, no two people will ever agree on everything, so someone will aways want some changes. 

--
Cheers, Gilad

[Matthew Butler]

Thanks for the response. And it's also why I was on the fence about much of it myself. In particular with the addition of new keywords or making immutable the default.  And I agree, you can please some people some of the time, but you can not please all of the people all of the time =) That said, there is so much with dart, and the dev teams, to be pleased with!

Thanks to all the team, and for making the hard choices that are so easy for us all to criticize ;)

Matt

[Alex Tatumizer]

Making everything final by default is really risky, but adding a backtick synonymous with final is not IMO.
so instead of
final int i=0;
you write
int `i=0;

what is the risk here?

[W. Brian Gourlie]

Making everything final by default is really risky, but adding a backtick synonymous with final is not IMO.
so instead of
final int i=0;
you write
int `i=0;

A backtick looks horrendous and is not at all intuitive. 

[Florian Loitsch]

I wouldn't waste backticks on final variables. Backticks have the nice property that they can enclose things: `foo(x) == y`

Here you only need a marker.

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett

[Alex Tatumizer]

@Florian: you have already SO MANY ways to enclose things with '...', "...", ${...} etc - do you have a use case for more? You can always add $[...],
$(...) - all of them are good for enclosure.
At the same time, backtick is a rare symbol  that doesn't hurt readability when you don't need to enclose anything.

Another underused symbol in dart is back slash, but
int \x=0;
doesn't look especially great to me (though it might  be ok as umbrella operator :)

[Alex Tatumizer]

> A backtick looks horrendous and is not at all intuitive

We are getting used to notation. The major concern is that making such big deal out of final/non-final might now be justified in the first place,
then we will be really  barking a wrong tree and just waste good symbol (really VERY valuable one).
I've never seen the proof that meticulous use of "final" translates to significant reduction of bugs, I personally very much doubt it, but it's a good "selling point" - simply because many people believe so. To "sell" to enterprise, you have to accumulate a number of selling points, no matter if they are based on myths or not :)

[Alex Tatumizer]

Correction: ... might NOT be justified in the first place ...

[Cogman]

> I've never seen the proof that meticulous use of "final" translates to significant reduction of bugs,

It depends, I think the bug reduction doesn't come from final, per say, but rather the notion of "Everything should be immutable".  There the bug reduction is easy to see, especially in highly concurrent environments.  Making final easy to do would be more of a help to try and coax developers into the mindset of preferring immutable data structures over mutable ones.

[W. Brian Gourlie]

then we will be really  barking a wrong tree and just waste good symbol (really VERY valuable one).
I've never seen the proof that meticulous use of "final" translates to significant reduction of bugs, I personally very much doubt it, but it's a good "selling point" - simply because many people believe so.

These are both entirely subjective statements.  I think your opinion of a backtick operator is clearly in the minority.  That being said, you've made your case for it, why the need to practically hijack the thread trying to convince people that a backtick operator would be great (or some other weird unicode character, for that matter)?

[Aliaksandr Zhuhrou]

I personally like the scala way: - 

    var for mutable 

    val for immutable.

This short, symmetric and familiar to many Java programmers who has experimented with scala.

2013/3/5 W. Brian Gourlie <bgou...@gmail.com>

then we will be really  barking a wrong tree and just waste good symbol (really VERY valuable one).
I've never seen the proof that meticulous use of "final" translates to significant reduction of bugs, I personally very much doubt it, but it's a good "selling point" - simply because many people believe so.

These are both entirely subjective statements.  I think your opinion of a backtick operator is clearly in the minority.  That being said, you've made your case for it, why the need to practically hijack the thread trying to convince people that a backtick operator would be great (or some other weird unicode character, for that matter)?

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

--
Contacts:
  telephone: +375291637178

  skype: zhygr34

[Alex Tatumizer]

The only reason I talk about backtick is that := is not tenable, and doesn't fully address the problem under discussion.

class Point {
  num x;
  num y;

  Point(this.x, this.y);

}
Where do you see assignment here? How to declare x, y final? with "final"? This is the MAJOR use case where := doesn't help at all.

The proposal about := has another interesting part:
"Furthermore, if x was defined as mutable binding one could convert it to immutable by making an assignment
of the form
  x := 1;
"

Are you serious?
What about this:
var x;
if (smth==0) {
   x:=5;
}
Does it declare x final? (This is just a tip of the iceberg)

Same relates to var/val. I don't know about scala, but in dart you can write
num x=0;

where do you put your var/val here? say "val num x=0"? Why not "final num x=0" then? Again, major use case is not addressed.
So we are left with the only place where you can attach SOME marker in the meaning of "final": the name of a variable at the point of declaration.
It's not the "opinion", it's a statement of fact. Whether it's a backtick or another symbol is a different issue.


P.S. For weird characters I proposed: do you have any sense of humor? I thought, it could be understood
from context that skull is just a funny symbol for the concept.

[mythz]

Yes please stop pushing backtick, you've said your piece - it has never been used or considered before for assignment or immutability - for good reason.

I think the currently proposed options are:

//mutable - i.e. what we're trying to differentiate from...

var a = 10; 

int a = 10;

//immutable

val a = 10;  

let a = 10;  

var a := 10;

var! a = 10; // or int! a = 10

!var a = 10; // or !int a = 10

int `i = 10; 

Are there any that I've left out?

[Cogman]

We could go crazy and say that variable names with all caps are immutable... (I don't particularly like this, but just throwing it out).

for example, var BOB = 5 would make poor ole bob immutable.

Pros: most naming conventions I've seen follow the "All upper case constants" convention

Cons: Seems very magical to me, also single letter variable would be a bit strange. Also, you might have to have special characters be considered such as the '_'.  It could also be a bad thing for internationalization.

[Alex Tatumizer]

> it has never been used or considered before for assignment or immutability - for good reason

> var! a = 10;

Ruby:

In general, methods that end in ! indicate that the method will modify the object it's called on. Ruby calls these "dangerous methods" because they change state that someone else might have a reference to. Here's a simple example for strings:

foo = "A STRING"  # a string called foo
foo.downcase!     # modifies foo itself
puts foo          # prints modified foo

So, it really WAS used to denote immutability - just with the opposite sign.

[Alex Tatumizer]

Guys, I'm asking your permission to criticize your proposals.

Thank you.

This thread started (post#3) with the following statement by Gilad:
> I believe final should be the default. 

Then, after intensive exchange of mostly untenable suggestions that don't make the slightest sense (but supposedly were not humorous!), out of nowhere, came two ideas:

1) exclamation mark

2) all capitals

What is exclamation mark, anyway?

As usual, let's go to wikipedia:

"The exclamation point is a punctuation mark usually used after an interjection or exclamation to indicate strong feelings or high volume (shouting)..."

Now tell me: why the trivial declaration, which was even supposed to become a default, should be expressed with a construct that normally conveys strong feelings and/or shouting?

Same question about all capitals.

[Cogman]

> Same question about all capitals.

The main reason I proposed that was due to convention (see http://horstmann.com/bigj/style.html for at least one style guide that suggests this).  Of course this comes from the days of C where all caps was used primarily to let the user know that "Hey, this code is a macro".

That certainly does not mean that I think it is a great idea. I don't know how well it fits in with the dart coding styles as a whole. It seems a bit magical for me as well.  All caps for constants predates the notion that all caps = shouting.

[Alex Tatumizer]

@Thomas: constants are statistically rare. If 99% of your code were  constants, then probably we would use all caps for regular vars instead.

Unfortunately, in year 2013, we are still limited to the same set of characters as in 1950. No umbrellas, no skulls, no bold, no color.
Why? I don't know. I don't think there's any technical reason for this. 

 

[Girish Varma]

I will add one more to the list,

// immutable

int a : 10;

var a : 10;

This is also consistent with optional parameters in functions, since function arguments are immutable.

Though i do not agree that adding this one will result in dart loosing its core audience, for the following reason:

1. immutable bindings are commonly used(many people in this thread has agreed).
   
2. Syntax proposed is very simple and doesn't break any code.
   

Dart already introduces syntax not there in other languages and that is ok if it provides benefits. I feel this one surely has enough benefits.And actually the syntax already exists for optional parameters.

[Ladislav Thon]

> This thread started (post#3) with the following statement by Gilad:
>
> > I believe final should be the default. 
>
> Then, after intensive exchange of mostly untenable suggestions that don't make the slightest sense (but supposedly were not humorous!), out of nowhere, came two ideas:
> 1) exclamation mark
> 2) all capitals

Here's my personal wish: I don't want Dart to add a lot of punctuation. I think I would tolerate it in type annotations, should we get any new (function types, union types, nullable types), but that would be pretty much it. I would hate punctuation for declaring variables final -- and in the end, I don't think it's crucial for Dart to have final by default.

(For what it's worth, I'd much rather have the ability to declare classes final so that they can't be subclassed!)

LT

[Ladislav Thon]

> At the same time, backtick is a rare symbol  that doesn't hurt readability

Except that there is a bunch of fonts out there where the backtick glyph looks similar to the apostrophe glyph. (And what's worse, there is a lot of people that use these two characters interchangeably. I think that backticks will never be given any meaning in Dart.)

LT

[Dirk Detering]

Am 05.03.2013 04:33 schrieb "Alex Tatumizer" <tatu...@gmail.com>:
>
> Unfortunately, in year 2013, we are still limited to the same set of characters as in 1950. No umbrellas, no skulls, no bold, no color.
> Why? I don't know. I don't think there's any technical reason for this. 

I do!
It is the fact that a standard keyboard has a limited set of (what? 104?) keys with a much more limited set of internationally overlapping characters. Keyboards are mainly used to write text beside code.

I do not want to install and learn a very special keyboard layout only to write one specific prog-lang's code.
And when I write code on different devices and OSes I do not want to research first the best way to input some unicode character.

Although I sometimes find e.g. functional code written with single character arrows (thin and fat) and a correct lambda sign intriguing, I cannot imagine to maintain a really large code base full of special signs.
It makes keyboard input ineffective.

E.g. the decision of architectureWare to use guillemets in their template code was a really bad choice outside of France.On a german keyboard on windows you end up with endless Alt+0xxx on num block. Don't even know how to do on linux, not to mention my smart phone.

So: Yes, it looks intriguing first, but is not practicable in large. Please stop proposing special unicode signs for international coding.

KR
Det

[Alex Tatumizer]

.>On a german keyboard on windows you end up with endless Alt+0xxx on num block

And you editor doesn't support setting up some CTRL/something for this? Strange.

Just in case, please check this out:

http://www.artlebedev.com/everything/optimus/popularis/

[Dirk Detering]

All in support for Lad (regarding punctuation and backticks), except

Am 05.03.2013 06:00 schrieb "Ladislav Thon" <lad...@gmail.com>:
> and in the end, I don't think it's crucial for Dart to have final by default.
>
> (For what it's worth, I'd much rather have the ability to declare classes final so that they can't be subclassed!)
>

The need to declare classes final comes not so often to me.
The wish to declare objects immutable very often. This is done by declaring all attributes final.
Often enough when reviewing code I wish Java had final as default too, seeing weird code structure or even runtime errors due to reckless variable reuse.
This is solved by declaring local variables final.

Altogether this follows Effective Java Item 15 "minimize mutability", (beside the fact that it is considered good style in Scala and enforced by Haskell for good reasons).

KR
Det

[Dirk Detering]

Am 05.03.2013 06:30 schrieb "Alex Tatumizer" <tatu...@gmail.com>:
>
> And you editor doesn't support setting up some CTRL/something for this? Strange.
>

You haven't understood: I don't want to make coding in a PL depending on features a certain editor(*) may have!
Some code in a certain language must be writable everywhere.
I do not further discuss this topic.

(*) which ranges from a full blown IDE over UltraEdit, vim in a terminal window, over some office word processor over an email program down to a simple online chat input field.

[Ladislav Thon]

> The need to declare classes final comes not so often to me.
> The wish to declare objects immutable very often.

Preventing subclassing is actually a part of that.

But then, with the ability to implement an implicit interface of each class, almost all guarantees are pretty weak. If you accept instances of your library class from the outside, you can never be sure if it really is an instance of your class.

(Asking for a way to prevent subclassing should probably mean that I also ask for a way to prevent implementing the implicit interface. I'm not sure about that.)

LT

[geevi]

That is one more reason we didn't go that way. You need a keyword that indicates that something is mutable. Hard to find something familiar/short/attractive.

What about

  int a : 10;

  var a : 10;

This is also consistent with optional parameters in functions, since function arguments are immutable.

I do not agree that adding this one will result in dart loosing its core audience, for the following reason:

1. immutable bindings are commonly used(many people in this thread has agreed).
   
2. Syntax proposed is very simple and doesn't break any code.

1. the syntax already exists for optional parameters.

[mythz]

out of nowhere, came two ideas:
1) exclamation mark

Alex, to reduce diluting the signal of this thread please read before posting unnecessarily.

I've already listed the sources for '!':

Looking at what others are doing there was a C# proposal for using a '!' suffix:
http://twistedoakstudios.com/blog/Post330_non-nullable-types-vs-c-fixing-the-billion-dollar-mistake

The annotations for the closure compiler use the '!' as a prefix:
https://developers.google.com/closure/compiler/docs/js-for-compiler

let! is also used for an asynchronous binding in F#

http://msdn.microsoft.com/en-us/library/dd233250.aspx

These are all examples of using an '!' to annotate either a binding or a variable contract which are analogous to an immutable definition. 

But it's still only a suggestion (based on prior usages and proposals), its completely up to the decision makers which construct is best for Dart.

Note: most people on this thread have just shared their constructive proposals and provided reasoning for them and have left it open for the language and API designers to choose without constant re-iteration.

Please consider unnecessarily hi-jacking this thread and allow other people a chance to share their proposals as well.

[George Moschovitis]

 

int x = 3; // immutable

This would be a backwards incompatible change. And would stand to break a fair amount of code.

Backwards incompatible changes happen all the time in the current version of Dart.

 

var x = 3; // mutable

var int x = 3; // mutable

The latter of which I'm not a fan of, too many key words to declare a statically checked variable. 

That's the point, mutable should be inconvenient instead of the other way around (i.e. final int x = 3).

 

-g.

[Ladislav Thon]

int x = 3; // immutable

This would be a backwards incompatible change. And would stand to break a fair amount of code.

Backwards incompatible changes happen all the time in the current version of Dart.

Not in the language itself. The language is said to be stable since M1. Maybe some tiny changes (method 'call' -> 'operator ()' was mentioned, not sure if it will happen), but nothing so disruptive.

LT

[Dirk Detering]

Am 05.03.2013 07:23 schrieb "Ladislav Thon" <lad...@gmail.com>:
>
> > The need to declare classes final comes not so often to me.
> > The wish to declare objects immutable very often.
>
> Preventing subclassing is actually a part of that.

Not for my intention so far, but interesting point!
I'll think about it.

>> But then, with the ability to implement an implicit interface of each class, almost all guarantees are pretty weak. If you accept instances of your library class from the outside, you can never be sure if it really is an instance of your class.
>

Well, that is your concern about subclassing, and was so far no problem for me as I did not look at the behaviour but the value.
Let them subclass, as how they use my lib is their responsibility.
My concerns are more the other direction:
Ensure that instances (values) a lib gives away aren't changed outside, avoiding side effects leaking back into the lib.
This may even be a lib internal concern, if we think about async/parallel/concurrent processing.

> (Asking for a way to prevent subclassing should probably mean that I also ask for a way to prevent implementing the implicit interface. I'm not sure about that.)

Regarding that this problem can only manifest itself on the boundaries where instances are exchanged, I cannot see what real necessity exists for avoiding subclasses.
If a class' implementation is absolutely vulnerable, it should not be part of the boundary, not participate in the exchange.
This may not be achievable in all cases, but this design rule reduces the cases where it is a problem to the minimum.
You can't reduce data exchange the same way. Thus value objects should default to immutable, i.e. attributes are final.

KR
Det

[Alex Tatumizer]

There's a palliative solution - not sure it makes sense, but there's a chance.: 

The idea is: 

1. if variable is provably final(*), treat it as final (even if not explicitly declared as such)

2. In the editor, use different highlighting styles for final (no matter explicitly or implicitly) and non-final variable names (at the point of declaration).

3. Use "brighter" style for non-final vars, allegedly to draw attention to them, with a hidden goal to motivate programmer to consider making it provably final.

(*) notion of "provably final" is TBD. but roughly it means: 

- it could be declared final - compiler doesn't see any problem with that 

- compiler is sure that application has no way to modify the variable other than via reflection. E.g., public instance members cannot be provably final.

Again, I'm not sure it's a tenable idea; (if not, it's still interesting to know why)

[Dirk Detering]

Am 06.03.2013 05:53 schrieb "Alex Tatumizer" <tatu...@gmail.com>:
>
> There's a palliative solution - not sure it makes sense, but there's a chance.: 
> The idea is: 
> 1. if variable is provably final(*), treat it as final (even if not explicitly declared as such)

Sorry I don't see the sense here. What means "treat it as final"?
Final is not a result of some analysis but an intention communicated to the analyser.

In your case, if someone assigns to the variable, compiler would simply not see it as final anymore, so what?
It can't decide if this is by intention or a bug.

If OTOH the developer explicitly or the spec implicitly defines a certain variable as final, analyser would show an error when he detects a reassignment. And that is part of "treat it as final" for me.

> 2. In the editor, use different highlighting styles for final (no matter explicitly or implicitly) and non-final variable names (at the point of declaration).
> 3. Use "brighter" style for non-final vars, allegedly to draw attention to them, with a hidden goal to motivate programmer to consider making it provably final.

Sorry, but consistency check should be done by the analyser/compiler, not per optical control by a developer sitting in front of a necessarily full fledged IDE.

>
> (*) notion of "provably final" is TBD. but roughly it means: 
> - it could be declared final - compiler doesn't see any problem with that 
> - compiler is sure that application has no way to modify the variable other than via reflection. E.g., public instance members cannot be provably final.
>

Right. But especially here final plays its useful role!

> Again, I'm not sure it's a tenable idea;

I don't see how it is. So please don't post such ideas prematurely.

[Alex Tatumizer]

> In your case, if someone assigns to the variable, compiler would simply not see it as final anymore, so what?
> It can't decide if this is by intention or a bug.

Yes, highlighting will change, that's it. That's all compiler can do. "Treat it as final" means "for the purposes of highlighting".
That's the best this editor can do to show you which vars are factually final, and which are  not. What syntax highlighting is about? Visual help.

> So please don't post such ideas prematurely.

This is not a polite expression. You could say "meaningful, but not convincingly" or something to that effect.
If it doesn't make sense to you, just say so, without issuing comical commands.

[Dirk Detering]

2013/3/6 Alex Tatumizer <tatu...@gmail.com>

> In your case, if someone assigns to the variable, compiler would simply not see it as final anymore, so what?
> It can't decide if this is by intention or a bug.

Yes, highlighting will change, that's it. That's all compiler can do. "Treat it as final" means "for the purposes of highlighting".
That's the best this editor can do to show you which vars are factually final, and which are  not. What syntax highlighting is about? Visual help.

What compiler/analyser is about: technical help. Avoidance of errors or possible bugs.

What programming language is about: logic and reasoning.

> So please don't post such ideas prematurely.

This is not a polite expression. You could say "meaningful, but not convincingly" or something to that effect.
If it doesn't make sense to you, just say so, without issuing comical commands.

Sorry for that, wasn't meant as rude as it may have sound.

[Alex Tatumizer]

> Sorry for that, wasn't meant as rude as it may have sound.

Accepted. Never mind :)

It may be the case where highlighting can help a bit  It's hard to say a priory how effective it might be though.

BTW, right not highlighting in dart editor is not very consistent:     int a; var x; - for some reason, x is highlighted, but not a, so it's not clear what highlighting really signifies. (just an aside, no relation to the issue at hand).

[Alex Tatumizer]

@Dirk: believe you or not, dart editor already tries to highlight initialized variables differently (though not consistently).
E.g.
Example 1:
var x; // uninitialized - colored differently  at declaration and initialization, but not re-assignment.
x=5;  // first initialization - highlighted
x=7;  // remains black

Example 2:
var x=10; // x is black right from start.

However, if you use "int" instead of "var", the magic disappears.

[Dirk Detering]

2013/3/6 Alex Tatumizer <tatu...@gmail.com>

@Dirk: believe you or not, dart editor already tries to highlight initialized variables differently (though not consistently).

 Alex, please!

Highlighting is not a topic here. Yes IDE can do fancy things.

That's a convenient help, but we're talking about language features and their defaults.

[kc]

On Tuesday, March 5, 2013 7:29:29 AM UTC, George Moschovitis wrote:

Backwards incompatible changes happen all the time in the current version of Dart.

 

var x = 3; // mutable

var int x = 3; // mutable

The latter of which I'm not a fan of, too many key words to declare a statically checked variable. 

That's the point, mutable should be inconvenient instead of the other way around (i.e. final int x = 3).

 

Also, the advantage of this inconvenience is it could mitigate against users making unnecessary type annotations. And 'var' would have more clearly related to local type inference.

var x = 1; // x is typed to int (in the analyser)

var int x; // uninitialised x is typed to int (in the analyser)

K.

[kc]

'val' looks good. It's a succinct way to declare immutable bindings.

Also 'let'.

Anything but final. Dart being too Java-ery could actually turn people off:

This appeared in my twitter stream during Google IO:

https://twitter.com/brucel/status/335097598358740992

K.

[Matthew Butler]

Yes, well unfortunately you're going to get comments like that anywhere.

For instance, look at the comments (sort by oldest) on this article: http://news.cnet.com/8301-1023_3-57584979-93/google-dart-will-rescue-browsers-from-javascript/

You're going to get comments regardless of what verbage the language uses. However keeping it familiar will help bring Java developers to dart. I see no reason that dart should set such a massive breaking change now for the sake of two characters, which will make the language less familiar to those coming from java, c#, etc.

Matt 

[Gen]

I do not like "val" because it looks like and might sound like "var".
And "let" might come with Ecmascript 6. With the same meaning ?

Anyway, a new set of keywords is no effort compared to the remaining differences for a Java or Javascript programmer.
Keywords and even general syntax are never a massive breaking changes in my opinion.

[kc]

On Friday, May 17, 2013 8:27:53 PM UTC+1, Matthew Butler wrote:

You're going to get comments regardless of what verbage the language uses. However keeping it familiar will help bring Java developers to dart. I see no reason that dart should set such a massive breaking change now for the sake of two characters, which will make the language less familiar to those coming from java, c#, etc.

That's it though. People with any taste have move on from Java and even C#.

K. 

[jim.trainor.kanata]

That's it though. People with any taste have move on from Java and even C#.

... I'm sympathetic, but the rest of the population, the untold masses with no taste, who are still writing a ton of Java and C#, and will need an outlet for that experience when their employers are finally comfortable moving them into web development... queue Dart, which they'll pick up in an afternoon, thus remaining in good favor with the boss because they will have saved their fretting manager thousands and thousands of dollars in retraining expenses.  (Oh yeah... it's fast, and can produce high quality, professional, code, to boot.)

Dart is almost pre-determined to offend many early adopters because it intentionally draws from the conventional while the early adopters are drawn to the unconventional.

[kc]

On Friday, May 17, 2013 9:30:05 PM UTC+1, Jim Trainor wrote:

... I'm sympathetic, but the rest of the population, the untold masses with no taste, who are still writing a ton of Java and C#, and will need an outlet for that experience when their employers are finally comfortable moving them into web development... queue Dart, which they'll pick up in an afternoon, thus remaining in good favor with the boss because they will have saved their fretting manager thousands and thousands of dollars in retraining expenses.  (Oh yeah... it's fast, and can produce high quality, professional, code, to boot.)

Dart is almost pre-determined to offend many early adopters because it intentionally draws from the conventional while the early adopters are drawn to the unconventional.

I think early adopters creating powerful apps quickly will be the catalyst for adoption by others. As long as the syntax isn't too unfamiliar/outlandish.

The 'final' issue is like 'new'. It's a keyword that is going to be typed again and again and again.

Best make it succinct - like 'val' - and in the case of 'new' optional. 

'val' has good prior art in Scala and other functional languages. As does 'let'.

Point p = new Point(0,0); // good grief. 1995.

val p = Point(0,0); // This looks like a language for 2013 and beyond for building modern structured Web Apps with Web Components!

K.

[Don David Alegria]

if I should come up with a different/easy statement .. why not a simple underscore ? _obj _var _function()?

final is a clear statement

val can be easily confused with var. Also I've seen it reserved for value many times

let sounds more like a function... 

On Saturday, March 2, 2013 12:28:49 AM UTC+1, W. Brian Gourlie wrote:

I prefer using single assignment variables when possible.  I find myself not doing this simply because littering the code with "final" looks much worse than "var."  Can we get a more terse single assignment keyword?

[Gen]

New keywords can be learned or forgotten in few seconds.
But there is no way an average Javascript and mabye even Java programmer learns the serious stuff and the subtle differences of Dart in 24 hours.

[Gen]

If he can, then he can learn almost any language in a reasonable or even comparable amount of time.

[kc]

On Friday, May 17, 2013 10:21:30 PM UTC+1, Gen wrote:

New keywords can be learned or forgotten in few seconds.
But there is no way an average Javascript and mabye even Java programmer learns the serious stuff and the subtle differences of Dart in 24 hours.

If Dart is done right no reason why it can't avoid the tedious boilerplate of Java and the weird corners of Javascript.

With a famiiar-ish syntax which reflects the clean core semantics of the DartVM. And is pleasurable to code in.

K.

[Jim Trainor]

I would expect a developer whose experience is limited to Javascript to have more trouble because they are not (may not be) accustomed to the more structured style of programming that comes with Dart. The paradigm shift will cause a problem, not the language. I would expect significantly less trouble from an experienced Java/C#/C++ programmer. 

Of course not all details in a day.  But to setup a simple development environment and see something work and understand what they just did, yes a day for an experienced programmer.

[Ladislav Thon]

> Point p = new Point(0,0); // good grief. 1995.
> val p = Point(0,0); // This looks like a language for 2013 and beyond for building modern structured Web Apps with Web Components!

1995: Point p = new Point(0, 0);
2005: p = Point 0, 0
2015: val p = Point(0, 0);

Really?

LT

[Alain Ekambi]

Hmm java devs have GWT. We try Dart cuz it's Dart not because it's better than Java

[罗勇刚(Yonggang Luo)]

the final keyword is acceptted consider the familiar of final, because it's not redundant keyword, people just want a shorter form keyword,  but the new keyword is really redundant,  its comes with no benefit except makes dart looks like Java or other static typed language, i am wonder what's kind of reason not drop 'new', it's possible some kinds of software engineering reason,  but i don't gotcha that

在 2013-5-18 下午3:46，"mezoni" <andrew...@gmail.com>写道：

If the compiler is not "stupid" then this is normal.

void main () {

   final int i;

   if (true) {

     i = 0;

   } Else {

     i = 1;

   }

   print (i);

}

Dart compiler (I think) more like 'stupid'.

Even it compile at runtime ...

Because if you run script in "checked" compiler MUST compile all code paths and analyze code statically before executing.

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

[kc]

On Saturday, May 18, 2013 7:51:32 AM UTC+1, Ladislav Thon wrote:

2005: p = Point 0, 0

Nope. Do not want to lose the parens for function calls - Ruby or functional style.

Familiar *should* mean calls to a function/constructor have parens - and assignment uses '='.

var p = Point(0,0);

But immutable bindings should have a succinct readable keyword - as it will be used so frequently.

Gilad B. preferes val. Gilad does not like new. Where is the familiar commandment - Thou shalt look like Java - coming from? 

Do the masses really need their 'final' and 'new' blankies.

K.

[Gen]

Gilad seems to prefer final by default.
This means no "var" and no "val" ?

Just:
x = something;

Seems good to me.