Notes from June 4 language meeting

447 views
Skip to first unread message

Bob Nystrom

unread,
Jun 6, 2013, 1:11:13 PM6/6/13
to General Dart Discussion
Here's my notes. As usual all mistakes are my own:

are boxed doubles identical?

There is a bug where doubles with the same value may return false for identical() because they have been boxed to different objects.

Lars said it's been discussed. For doubles, identical() should return true based on value. We don't want the language spec to have to mention boxing so that the VM is free to optimize how it wants.

Gilad asked if NaN is identical to NaN?

Lars says yes. It's identical but not equal. Gilad will fix the spec.

change uninitialized field error to warning?

Uninitialized final fields are currently an error in the language. Kasper suggests making it a warning. It seems in line with other stuff in language. It's easy to associate some value with an uninitialized final.

Gilad says we can do this and asked why Kasper ran into it. Kasper saw some bugs where implementations behaved differently in some related corner cases.

Lars doesn't have a problem with it.

const instance variables

Gilad's view is that they should work like statics except for scoping. Apparently, though, it's complicating the VM implementation of instance metadata. Three solutions:

1. No const instance fields.
2. Metadata is statically scoped.
3. Try to do it correctly.

Lars likes 1. I say 1 simplifies things for users. Right now, people get confused with static final const etc. Gilad is OK with 1.

I asked if the syntax would be "static const" or just "const"? Users get confused when having to do "static" with constants.

Lars says they are confused because they don't understand the system. Requiring "static" will help them understand what's going on.

what liberties can editor take with type system

[I didn't have a lot of context here, so I'm fuzzy on the details.]

Dan Rubel asked how flexible the analyzer can be with the Dart type system and how it can extend it.

Gilad is OK with things like type inference for auto-complete. What other things should we allow?

Lars says step one is to do exactly what the spec says. Going beyond that and helping user with refactoring and stuff is great. Using it for warnings gets strange. If you go from the Editor to command line, you would get different warnings.

Dan's concern is more about false positives. We should look at code and see if they use constructs like guarded type promotion.

Lars says if users are using these constructs a lot, we should change the language to support them. If you want to have a type guard match thing we should have a different construct. But for now, the analyzer should go with the current spec.

Kasper says we have to be careful if we report fewer warnings because users will get used to that and then get confused if other tools follow the spec more closely and have more warnings.

stack traces

Lars had lots of discussions back and forth with some internal Dart users. One issue is about catching exceptions and capturing stack traces and how its painful for some. Lars is OK if severe errors like noSuchMethod automatically get a stack trace.

Kasper says that would mean two ways to access stack traces. I note that with async, it's three. Lars says Florian has some idea of a constant flag to enable/disable stack trace capturing.

Gilad asks if the spec would have to lay out which errors get stack traces and which don't? Lars says they'll come up with a proposal.

Cheers!

- bob

Ladislav Thon

unread,
Jun 6, 2013, 2:17:00 PM6/6/13
to mi...@dartlang.org
change uninitialized field error to warning?

Uninitialized final fields are currently an error in the language. Kasper suggests making it a warning. It seems in line with other stuff in language. It's easy to associate some value with an uninitialized final.

Gilad says we can do this and asked why Kasper ran into it. Kasper saw some bugs where implementations behaved differently in some related corner cases.

Lars doesn't have a problem with it.

I do. Well, I probably don't, 'cause I don't fully understand the context... Does it undermine immutability? I hope not.
 
const instance variables

Gilad's view is that they should work like statics except for scoping. Apparently, though, it's complicating the VM implementation of instance metadata. Three solutions:

1. No const instance fields.
2. Metadata is statically scoped.
3. Try to do it correctly.

Lars likes 1. I say 1 simplifies things for users. Right now, people get confused with static final const etc. Gilad is OK with 1.

I asked if the syntax would be "static const" or just "const"? Users get confused when having to do "static" with constants.

Lars says they are confused because they don't understand the system. Requiring "static" will help them understand what's going on.

I don't have a problem with "static const", but "static" really looks redundant here. Assuming one knows what a compile-time constant in Dart is.
 
what liberties can editor take with type system

[I didn't have a lot of context here, so I'm fuzzy on the details.]

Dan Rubel asked how flexible the analyzer can be with the Dart type system and how it can extend it.

Gilad is OK with things like type inference for auto-complete. What other things should we allow?

Lars says step one is to do exactly what the spec says. Going beyond that and helping user with refactoring and stuff is great. Using it for warnings gets strange.

Why? This is what static analysis tools have been doing for ages. It won't take long before some static analyzer for Dart will appear and I'm sure it's going to do extra-linguistic checks based on empirical evidence.

LT

jim.trainor.kanata

unread,
Jun 6, 2013, 2:22:58 PM6/6/13
to mi...@dartlang.org
Thanks for posting this stuff. It's interesting to see the inner workings.

Regarding the liberties with the type system:

I think you should stick to the spec for warnings and errors. A user flipping between editors, or analyzer implementations, shouldn't be faced with a different set of warnings just because they changed environments. That may start happening if a culture of going above and the spec. is established.

Extra tools, or modes of operation, can be used to enforce best practices above and beyond the specification. This is the pattern we see with other languges. e.g. C has lint, Javscript has JSList, Java has findbugs, gcc has a raft of options to activate extra warnings.

<two-cents/>

Bob Nystrom

unread,
Jun 6, 2013, 3:57:19 PM6/6/13
to General Dart Discussion
On Thu, Jun 6, 2013 at 11:17 AM, Ladislav Thon <lad...@gmail.com> wrote:
change uninitialized field error to warning?

Uninitialized final fields are currently an error in the language. Kasper suggests making it a warning. It seems in line with other stuff in language. It's easy to associate some value with an uninitialized final.

Gilad says we can do this and asked why Kasper ran into it. Kasper saw some bugs where implementations behaved differently in some related corner cases.

Lars doesn't have a problem with it.

I do. Well, I probably don't, 'cause I don't fully understand the context... Does it undermine immutability? I hope not.

Not as I understand it. Final fields would still only be assignable in the constructor initialization list. All this means is that if you forget to initialize a final field, it will be a static warning instead of a "OMG stop the world" error.

 
const instance variables

Gilad's view is that they should work like statics except for scoping. Apparently, though, it's complicating the VM implementation of instance metadata. Three solutions:

1. No const instance fields.
2. Metadata is statically scoped.
3. Try to do it correctly.

Lars likes 1. I say 1 simplifies things for users. Right now, people get confused with static final const etc. Gilad is OK with 1.

I asked if the syntax would be "static const" or just "const"? Users get confused when having to do "static" with constants.

Lars says they are confused because they don't understand the system. Requiring "static" will help them understand what's going on.

I don't have a problem with "static const", but "static" really looks redundant here. Assuming one knows what a compile-time constant in Dart is.

It is a bit verbose, which is why I brought it up.
 
 
what liberties can editor take with type system

[I didn't have a lot of context here, so I'm fuzzy on the details.]

Dan Rubel asked how flexible the analyzer can be with the Dart type system and how it can extend it.

Gilad is OK with things like type inference for auto-complete. What other things should we allow?

Lars says step one is to do exactly what the spec says. Going beyond that and helping user with refactoring and stuff is great. Using it for warnings gets strange.

Why? This is what static analysis tools have been doing for ages. It won't take long before some static analyzer for Dart will appear and I'm sure it's going to do extra-linguistic checks based on empirical evidence.

There was some discussion on the team about this too. I believe the language team doesn't want to specify any flow-based type inference.

But the result is that this code generates a static warning:

foo(Object arg) {
  if (arg is String) print(arg.length);
}

That code is demonstrably correct, so I don't see how mandating a warning here helps users or lines up with Dart's "we'll even loosen the type system to avoid spurious warnings" philosophy. It's especially confusing to me because this code does not have a static warning:

foo(Object arg) {
  String arg2 = arg;
  print(arg2.length);
}

In the first example, I'm actually validating that the type is correct at runtime, but I still get a warning. Meanwhile, in the second example, there is zero actual validation at runtime and I don't get any warning to let me know I'm doing something unsafe. I'm not sure how either of these are helpful for users.

- bob



Greg Lowe

unread,
Jun 6, 2013, 6:48:54 PM6/6/13
to mi...@dartlang.org
Even if it's behind a flag or ide setting, I'd like to see the analyzer be able to do as much static analysis as Java or C#. From my limited use, the new analyzer seems to be very lenient.

For example the bug in yaml.isNotEmpty should never have been able to happen had the static analysis been sufficiently strict.

Thomas Løcke

unread,
Jun 7, 2013, 2:16:41 AM6/7/13
to mi...@dartlang.org


On Friday, June 7, 2013 12:48:54 AM UTC+2, Greg Lowe wrote:
Even if it's behind a flag or ide setting, I'd like to see the analyzer be able to do as much static analysis as Java or C#. From my limited use, the new analyzer seems to be very lenient.

For example the bug in yaml.isNotEmpty should never have been able to happen had the static analysis been sufficiently strict.


/agree 
Message has been deleted
Message has been deleted

peteroc

unread,
Jun 7, 2013, 11:47:38 AM6/7/13
to mi...@dartlang.org
I think the lenient analyser is a strength of Dart's. You can push some type checks out to runtime (if you run in checked mode). The more of this the better. I like not having a compiler slap me on the wrist for things I know will be ok. I'm sure most dynamic language users would feel the same.

Peter.

Bob Nystrom

unread,
Jun 7, 2013, 12:10:23 PM6/7/13
to General Dart Discussion

On Fri, Jun 7, 2013 at 7:52 AM, mezoni <andrew...@gmail.com> wrote:
In C# constants are...
1. Accesed as static fields. int color = Colors.Red.
2. Declared as static fields but without "static" keyword. const int red = 1, green = 2, blue = 3;.
3. They are not fields and not stored in memory. Just compile time values.

Right. They have the same semantics as Dart constants. The only difference is that they don't use the "static" keyword. Lars prefers to require that in Dart because he feels it makes it clearer to users that the constant is indeed static and not per-instance.

Cheers,

- bob
Message has been deleted
Message has been deleted
Message has been deleted

kc

unread,
Jun 7, 2013, 12:49:07 PM6/7/13
to mi...@dartlang.org
That's the kind of verbosity I dislike.

This clearly says to me that the const ORIGIN in defined once per class at compile time - and using const in this way makes sense:

class Point {
     const ORIGIN = Point(0,0);
     Point(this.x, this.y);
     ...
}

K.
 
Message has been deleted

Ladislav Thon

unread,
Jun 7, 2013, 3:54:37 PM6/7/13
to mi...@dartlang.org
>> The only difference is that they don't use the "static" keyword. Lars prefers to require that in Dart because he feels it makes it clearer to users that the constant is indeed static and not per-instance.

Lars no right here. Because he did not take into account all aspects.
1. Variables (value holders)
- Per class (static)
- Per instance (automatic)
- Per block (local)

2. Constants (values)
-  Value (non automatic, not static, not other but precompiled values)

Note that the const keyword in Dart has both meanings, 1 and 2. In static const Point ORIGIN = const Point(0, 0), the first const is a variable, the second is a value.

LT
Message has been deleted

kc

unread,
Jun 7, 2013, 4:58:02 PM6/7/13
to mi...@dartlang.org
On Friday, June 7, 2013 8:54:37 PM UTC+1, Ladislav Thon wrote:

Note that the const keyword in Dart has both meanings, 1 and 2. In static const Point ORIGIN = const Point(0, 0), the first const is a variable, the second is a value.


Well it would be clearer if the example covering points 1 and 2 could be expressed as:
const ORIGIN = Point(0,0); // no explicit call to const constructor needed. Or type annotation. Or static.

K.

Gen

unread,
Jun 7, 2013, 5:00:15 PM6/7/13
to mi...@dartlang.org
If "static const identifier" is possible then I wonder what "const identifier" will give me.

Right now I wonder why not writing:
const x = Point(...)
instead of:
static const x = const Point(...);

Or remove const for identifiers declarations and write:
static final x = const Point(...);
final x = const Point(...);

Zdeslav Vojkovic

unread,
Jun 7, 2013, 6:29:51 PM6/7/13
to mi...@dartlang.org
I find that Dart is quite inconsistent with regard to expectations from its target audience. Sometimes they are treated as highly intelligent people which can use and understand complex ideas or consequences of implementation (e.g. recent example with private fields in an abstract type), other times they need to be reminded of rather logical conclusions by requiring more ceremony in syntax.

I obviously fall into camp which sees `static const` as superfluous. If user is not confused by top level (thus non-static) constant, then he will hardly be confused by one declared in the class. constants are constants, after all, they are intended to be the same across the instances, otherwise they would be `final`

just my 0.02$


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

Message has been deleted
Message has been deleted
Message has been deleted

Gen

unread,
Jun 8, 2013, 4:05:05 AM6/8/13
to mi...@dartlang.org
Constants are not just compiletime values.
The objects const Point(0,0) or value PI or float.max must be available and therefore stored somewhere at runtime.

Why should I not decide from where I can access my constants ?
Static constant references / identifiers from library or class.
Constant values from library, class or instance.
 
Actually, I do not care where and how Dart stores what data at runtime.
As long as it is efficient.
AFAIK, a good C++ compiler can recognize compiletime expressions as constants.

Am Samstag, 8. Juni 2013 06:42:13 UTC+2 schrieb mezoni:
As I understand many people here confuse different things.
1. Expressions that produces constant values.
2. Expressions that not produces constant values.
3. Variables
4. Constants

1. Expressions that produces constant values.
5
1 + 2 + 3
const Point(0, 0)

2. Expressions that not produces constant values.
5 * x
x + y + z
Point(0, 0)

3. Variables
int i;
static int i;
var i;

4. Constants
const int PI = (3.14 * 2 + 1 - 1) / 2;
const Point ORIGIN = const Point(0, 0);

Remember that expression are not constants.
In this case constant is PI but not 3.14
const int PI = 3.14;

Even the constant declared in class this not means that it in depends on the fact will be created instance or not.

Class in this case plays the role of container of the visibility.
Special case of this is enum.
Look at this example. Not Dart but similar technique (constants).
enum Colors: int {RED, GREEN, BLUE};

Here are three elements in container.
But sizeof (Colors) not depends on number of constants.
sizeof (Colors)! = Colors.length * sizeof (int);
sizeof (Colors) == sizeof (int);

This is because constants not allocated (statically or automatically or on stack).
In this case Colors is a container of the visibility but not container of values.
Colors not store values ​​inside itself. It just for name qualification (separate namespace).

For knowledge:
The "static" keyword is a type storage specifier.
Constant not stored anywhere (meaning the area available to the programmer).
They not required type storage specifier.

kc

unread,
Jun 8, 2013, 5:09:37 AM6/8/13
to mi...@dartlang.org


On Friday, June 7, 2013 10:00:15 PM UTC+1, Gen wrote:
If "static const identifier" is possible then I wonder what "const identifier" will give me.

Right now I wonder why not writing:
const x = Point(...)
instead of:
static const x = const Point(...);
Yes.



Or remove const for identifiers declarations and write:
static final x = const Point(...);
final x = const Point(...);

This makes sense as well.

Maybe:
const x = Point(...)
Should be cosidered as shorthand for:
final x = const Point(...);

K. 

kc

unread,
Jun 8, 2013, 5:17:35 AM6/8/13
to mi...@dartlang.org
On Friday, June 7, 2013 11:29:51 PM UTC+1, Zdeslav Vojkovic wrote:
I find that Dart is quite inconsistent with regard to expectations from its target audience. Sometimes they are treated as highly intelligent people which can use and understand complex ideas or consequences of implementation (e.g. recent example with private fields in an abstract type), other times they need to be reminded of rather logical conclusions by requiring more ceremony in syntax.

That's a good observation.  The sweet spot for Dart should be - assume the target audience is intelligent - but who like all intelligent people appreciate the value of simplicity. 'const' at the moment fails that test. Dart could be massively successful if they took the simple approach - both for VM and syntax. Java style boilerplate is wrong for this language.

I obviously fall into camp which sees `static const` as superfluous. If user is not confused by top level (thus non-static) constant, then he will hardly be confused by one declared in the class. constants are constants, after all, they are intended to be the same across the instances, otherwise they would be `final`


Exactly.

K.
Message has been deleted

kc

unread,
Jun 8, 2013, 5:38:18 AM6/8/13
to mi...@dartlang.org
On Saturday, June 8, 2013 9:05:05 AM UTC+1, Gen wrote:

Actually, I do not care where and how Dart stores what data at runtime.
As long as it is efficient.
AFAIK, a good C++ compiler can recognize compiletime expressions as constants.


Yes - because Dart's  promise is simplicity - 'we will handle the performance for you'. 

That's why I dislike passing const's as parameters to functions:
var dt = myfunc(const  Duration(days:3));

It immediately raises too many questions in my mind - why is this const. Why is it that myfunc requires a 'const'  parameter - is it for metadata, switch, identical or performance. And why can't the compiler figure out that 'Duration(days:3)' is a const anyway.

Indeed, Dart's use of const seems to be similar to C++. But it would be much more straightforward if some classes could be defined upfront as immutable value type's with const constructors - which could be considered as having the same semantics as the 'built in' immutable value types - int, float, boolean and string.

const ORIGIN = Point(0,0); // Point is an immutable value class - which can thus be const-ified.

const TEST = Testing(0,0); // Testing is NOT an immutable value class - therefore this is a compile time FAIL

K.
Message has been deleted
Message has been deleted

kc

unread,
Jun 8, 2013, 7:23:36 AM6/8/13
to mi...@dartlang.org
On Saturday, June 8, 2013 11:30:24 AM UTC+1, mezoni wrote:
>> Const ORIGIN = Point (0,0); / / Point is an immutable value class - which can thus be const-ified.

But I'm not saying it's impossible.

It would be useful if immutable value types were part of the language - with syntax something like:

const class Point {
    Point(this.x, this.y); // const constructor
    int x; // final
    int y; // final
}

const ORIGIN = Point(0,0);
print(ORIGIN == Point(0,0)); // true
print(identical(ORIGIN, Point(0,0)); // true - and switch works as expected

K.

jim.trainor.kanata

unread,
Jun 8, 2013, 7:50:28 AM6/8/13
to mi...@dartlang.org
Dart's const isn't anything like C++ const IMO.  C++ const can be all over the place as part of a declaration, or a cast: function arguments, return types, references, pointers, class data members, globals, part of template types (did I mss any?).  It confuses the @#%#$% out of many (most?) developers in my experience... and even if you use it properly it can be cast away on a whim by a carefree developer.

When you see, or use, const in Dart you know, simply, that you've entered into a mode where dynamic types are more limited (err... unavailable). That's it.  With that perhaps comes some efficiency (for the VM) but I really don't care about that deeply as a developer. What I care about is that I now have to provide literals or other const objects in order to get a class constructed.... that's my first impression, at least, I can't really say I've contemplated it too deeply. I guess I just don't get bothered by that stuff.

kc wrote:

kc

unread,
Jun 8, 2013, 8:27:53 AM6/8/13
to mi...@dartlang.org

Lars says they are confused because they don't understand the system. Requiring "static" will help them understand what's going on.


Could lead to:

K.
Message has been deleted
Message has been deleted
Message has been deleted

Gen

unread,
Jun 8, 2013, 1:44:36 PM6/8/13
to mi...@dartlang.org
lol.

From chapter 2: The == operator tests whether two objects are equivalent. Two strings are equivalent if they have the same characters.

I could accept that different double objects are are considered identical.
But why ? Who would test equality by using the identical() function ?

But considering different NaN objects as identical but not equal is beyond my common sense.
What am I missing ?
 
Am Samstag, 8. Juni 2013 17:11:53 UTC schrieb mezoni:
>> are boxed doubles identical?
>> Gilad asked if NaN is identical to NaN?
>> Lars says yes. It's identical but not equal. Gilad will fix the spec.

As everything is simple with Lars. To be envied.
And God said, Let there be light. And there was light.
And Lars said, Let NaN will always be identical but not equal even they not identical. And there was NaN identical forever.

Alex Tatumizer

unread,
Jun 8, 2013, 1:50:30 PM6/8/13
to mi...@dartlang.org
@mezoni: equal doubles are identical because equal ints are identical.
Equal ints are identical because there's a subset of ints called "smi" that has no "identity" at all (not stored as object)
Since equals smis are identical by necessity, there's no choice but to extrapolate this rule to all ints.
And by implication, all numbers (doubles)

The notion of identity *probably* is useful mostly in one place: identity hashmaps.
In the context of identity hashmaps, you probably want equal numbers to be identical anyway - 

Alex Tatumizer

unread,
Jun 8, 2013, 2:07:45 PM6/8/13
to mi...@dartlang.org
@Gen: equality for doubles is defined as part of standard http://en.wikipedia.org/wiki/IEEE_754
NaN is not equals to NaN - that's how it's defined in standard. Don't ask anybody why. There are other arcane rules there.
It's like Unicode standard, which tells you that character is not a character - and you have to live with this.
  

Gen

unread,
Jun 8, 2013, 2:26:39 PM6/8/13
to mi...@dartlang.org
Thanks for the information. 
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted

Srdjan Mitrovic

unread,
Jun 8, 2013, 6:28:29 PM6/8/13
to General Dart Discussion



On Sat, Jun 8, 2013 at 9:57 AM, mezoni <andrew...@gmail.com> wrote:
>>  are boxed doubles identical?
>> There is a bug where doubles with the same value may return false for identical() because they have been boxed to different objects.

Interesting. 
How this fact can be considered as a bug?
If some values boxed to different objects that this not means that they must be identical.
Different objects are always not identical.
Where bug?

'identical' should produce same result regardless if we are running code in optimized (unboxed doubles) or optimized (boxed doubles) code. 

Cheers,

- Srdjan


Bug in that they incorrectly boxed (in different objects)?
Or bug in that the different objects considered not identical?

Equal for me when objects are tested for equality.
Different object can be considered equal or not equal, depending on the comparison operation.

But my "silly" head cannot understand how "different objects" can be "identical" even they are "equal".
If they "equal" then this not means than they must be always identical (even they are the "value" objects and "boxed").

I not understand what in Dart is "identical".
Just beautyful word?

Ladislav Thon

unread,
Jun 9, 2013, 2:02:15 AM6/9/13
to General Dart Discussion


> If user is not confused by top level (thus non-static)

Top-level is the same as static, except that it's not in a class (so it doesn't need a special keyword to distinguish between things that belong to the class and things that belong to instances). In fact, implementations can implement the top-level scope as a special class with all members static, and it will perfectly conform to the specification (and the VM is doing it).

LT

Ladislav Thon

unread,
Jun 9, 2013, 2:12:16 AM6/9/13
to General Dart Discussion


> This is because constants not allocated (statically or automatically or on stack).
> In this case Colors is a container of the visibility but not container of values.
> Colors not store values inside itself. It just for name qualification (separate namespace).

Constants ARE allocated, as they are normal objects.

And in fact, but that's an implementation detail, constants in the VM are stored in their classes (except of Smis, of course), so Colors here DOES store values inside itself. It's not important from the language point of view, though.

LT

Message has been deleted

Zdeslav Vojkovic

unread,
Jun 9, 2013, 9:00:03 AM6/9/13
to mi...@dartlang.org
I understand that. What I find strange is that it is expected that the users understand that implicit behavior for top-level consts, but somehow would not be able to understand that consts within the class behave in the same way.

As it seems that both Lars and Gilad agree with 'No const instance fields.' approach, there is no need to distinguish 'between things that belong to the class and things that belong to instances' - therefore, static is indeed superfluous, and we are back to initial argument of user not being able to understand that behavior.


--
Message has been deleted
Message has been deleted

Ladislav Thon

unread,
Jun 9, 2013, 11:18:04 AM6/9/13
to mi...@dartlang.org
I understand that. What I find strange is that it is expected that the users understand that implicit behavior for top-level consts, but somehow would not be able to understand that consts within the class behave in the same way.

I believe that it's just for sake of consistency. Everything that "belongs to the class, as opposed to the instance" is marked "static". In the top-level scope, there is no such distinction, therefore there is no such marker.
 
As it seems that both Lars and Gilad agree with 'No const instance fields.' approach, there is no need to distinguish 'between things that belong to the class and things that belong to instances' - therefore, static is indeed superfluous, and we are back to initial argument of user not being able to understand that behavior.

I agree with that and I also agree that in "static const", the "static" keyword is redundant and can easily be removed.

LT
Message has been deleted

Ladislav Thon

unread,
Jun 9, 2013, 11:50:03 AM6/9/13
to mi...@dartlang.org
>> I believe that it's just for sake of consistency. Everything that "belongs to the class, as opposed to the instance" is marked "static". In the top-level scope, there is no such distinction, therefore there is no such marker.

In most cases (not in scripting languages) keyword "static" means that data stored in ".bss" segment (part of the data segment containing statically-allocated variables).

This doesn't apply to languages that are implemented using a VM.
 
But this not means that "static" is only "per-class".

"static" means "per-class" in Java, C# and a bunch of other languages running in a VM.
 
Dart abusing this word.

No it doesn't. It uses the same word as Java and C# use.
 
Dart uses it not standart and thus creates more confusion.

This was true like 20 years ago. Not today.

LT
Message has been deleted
Message has been deleted

Ladislav Thon

unread,
Jun 9, 2013, 1:23:49 PM6/9/13
to mi...@dartlang.org
"static" means "per-class" in Java, C# and a bunch of other languages running in a VM.

Here we discuss "static const".

In this text, it looks like you are discussing "static" itself: In most cases (not in scripting languages) keyword "static" means that data stored in ".bss" segment (part of the data segment containing statically-allocated variables). But this not means that "static" is only "per-class". Dart abusing this word. Dart uses it not standart and thus creates more confusion. Anyway, this indeed isn't related to this discussion.

LT
Message has been deleted

罗勇刚(Yonggang Luo)

unread,
Jun 9, 2013, 2:17:10 PM6/9/13
to Dart
Propose add Nested class support.
so that we can use class as a namespace tool.

such as for HTML
new Element.Div()
It's very useful to orgnize those elements.

2013/6/10 mezoni <andrew...@gmail.com>:
>>> In this text, it looks like you are discussing "static" itself: In most
>>> cases (not in scripting languages) keyword "static" means that data stored
>>> in ".bss" segment (part of the data segment containing statically-allocated
>>> variables). But this not means that "static" is only "per-class". Dart
>>> abusing this word. Dart uses it not standart and thus creates more
>>> confusion. Anyway, this indeed isn't related to this discussion.
>
> Ladislav, I am just about that.
> About abuse 'static' not at all but in current context.
> Currently this topic have 57 messages.
>
> My words (message #8):
>>> In C# constants are...
>>> 1. Accesed as static fields. int color = Colors.Red.
>>> 2. Declared as static fields but without "static" keyword. const int red
>>> = 1, green = 2, blue = 3;.
>>> 3. They are not fields and not stored in memory. Just compile time
>>> values.
>
> From Bob Nystrom (message #10):
>>> Right. They have the same semantics as Dart constants. The only
>>> difference is that they don't use the "static" keyword. Lars prefers to
>>> require that in Dart because he feels it makes it clearer to users that the
>>> constant is indeed static and not per-instance.
>
> Even Bob Nystrom says " they don't use the "static" keyword".
> But you say "No it doesn't. It uses the same word as Java and C# use."
>
> I am just about that.
>
> --
> 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
>
>



--
此致

罗勇刚
Yours
sincerely,
Yonggang Luo
Message has been deleted
Message has been deleted

kc

unread,
Jun 9, 2013, 4:51:51 PM6/9/13
to mi...@dartlang.org
The obvious solution is to remove 'static'. With libraries it's not necessary.

And 'const' members are obviously effectively class level and can be accessed as such.

var p = Point(0,0);
print(p == p.ORIGIN); // true
print(p == Point.ORIGIN); // true

K.
Reply all
Reply to author
Forward
0 new messages