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 variablesGilad'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.
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 variablesGilad'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.
foo(Object arg) {if (arg is String) print(arg.length);}
foo(Object arg) {
String arg2 = arg;
print(arg2.length);}
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.
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.
>> 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.
--
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
As I understand many people here confuse different things.1. Expressions that produces constant values.2. Expressions that not produces constant values.3. Variables4. Constants1. Expressions that produces constant values.51 + 2 + 3const Point(0, 0)2. Expressions that not produces constant values.5 * xx + y + zPoint(0, 0)3. Variablesint i;static int i;var i;4. Constantsconst 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.14const 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.
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(...);
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`
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.
>> 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.
Lars says they are confused because they don't understand the system. Requiring "static" will help them understand what's going on.
>> 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.
>> 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?
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?
> 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
> 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
--
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.
>> 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).
But this not means that "static" is only "per-class".
Dart abusing this word.
Dart uses it not standart and thus creates more confusion.
"static" means "per-class" in Java, C# and a bunch of other languages running in a VM.
Here we discuss "static const".