Jeff, comments below:
>> Consider:
>>
>>
>> class Circle extends Shape {
>> print("Circle")
>> }
>> class Shape {
>> print("Shape")
>> }
>>
>>
>>
>> Should we see
>>
>>
> Circle
> Shape
>
> [note that static initialization code must now be put in 'static
> {...}'
> blocks]
>
> Class initialization is still an area of open investigation, but
> here is how
> I think it should work:
>
> 1/classes initialize in the order that they appear. Static fields get
> initialized in that order too. We want to avoid subtle changes in
> meaning
> due to implicit reordering of classes. We leave it to the programmer
> to
> define the correct order of initialization.
I would have thought that a slight modification may work better. I'd
propose initialization starting with order in the file and then doing
a recursive descent of base classes, doing the base classes first, and
making sure a class is initialized only once. That way a class static
initializer will always have its static base class members initialized
before it runs. This should be deterministic and not changing from
implementation to implementation.
Just doing class order will allow static initializers to run before
their base classes are initialized. This is problematic. Can you point
out where this model would file?
>
>
> 2/forward type references to types defined in the current
> compilation unit
> are allowed. As you pointed out, this is more relaxed than AS3 and the
> current RI and allows more programs to load successfully.
Good. What about across compilation units, that has to be allowed
also. Now that packages are gone and without explicit importing, you
must allow cross file references.
>
>
> 3/class instances can be created before the class statics have been
> initialized. Currently class static can be read before they are
> initialized
> and provide the default value of the storage type. I can imagine
> adding read
> barriers to static vars to ensure that they are initialized before
> use. We
> could disallow the instantiation of class instances before its
> statics are
> initalized, but that would seem to make completely safe programs
> illegal
> while not providing any more safety than a read barrier on static
> properties.
>
> Consider this case:
>
> class B extends A {
> static var a
> static {
> print ("static B")
> a = new A
> }
> function B () {
> print ("new B")
> }
> }
>
> class A {
> static var b
> static {
> print ("static A")
> b = new B
> }
> function A () {
> print ("new A")
> }
> }
>
> prints:
>
> static B
> new A
> static A
> new B
> new A [call to super constructor]
>
> Thoughts?
So in essence, the problem is creating an instance of a class while it
is being statically initialized. In general, I'd suggest throwing a
reference error if an instance of a class is attempted while its
static initializer is still executing, as it would usually be a
program design flaw. Better to move such code into a static method to
run after class initialization.
>
>
> Jd
>
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
