On 2009-11-19, at 16:53, Rami Ojares / AMG Oy wrote:
>
>> 3) In my experience, 99% of the uses of "method overloading" (as it is
>> called in C++), is simply to implement default arguments.
>
> I agree 99.99%
>
>> <method name="name" args="arg1:A1Type, arg2:A2Type = arg2Default"
>> returns="RetType"> ... </method>
>> or in script:
>> function name (arg1:A1Type, arg2:A2Type = arg2Default):RetType { ... }
>
>
> Well you see that's a notation I was not aware of.
> I have seen it in the source code but did not really know what it meant.
> That satisfies me. Thanks!
>
> Does this notation come from edition 4 or is it laszlo specific?
The script notation matches edition 4 (and as3). And I fully expect Harmony
will be very similar.
In general, there was a fair amount of acceptance of the as3 design, but it was
felt by a large fraction of that standards committee that it was just too large
a leap and that what was most sorely needed was to unify existing browser
implementations (most importantly to resolve JScript vs. Javascript) first.
The primary thrust of Harmony seems to be to see if there is a way to define
classes in Javascript as purely syntactic sugar whose implementation can be
formally defined _in_Javascript_. (Leaving open to implmentors the choice of
optimizing classes in any way they like, so long as they obey the formal
semantics.) This is not a bad thing. I would say that OpenLaszlo is a proof
that it can be done, because our runtime does nearly that: implements
edition4/as3 classes on edition3 runtimes (the so-called DHTML runtime). It
will be nice to see this standardized and supported directly in browsers.
You will notice that OpenLaszlo intentionally _does_not_ require you to specify
method signatures in LZX. It is our intent that LZX code retain it's dynamic
flexibility and that the compiler will "fill in the blanks" when compiling to a
more strict runtime. There are a few places where the strict runtime leaks up
and takes away some of the dynamicity that was available on swf8, but we have
tried to make that the exception. We believe that the
rapid-prototyping/exploratory capability of LZX is a strength in its primary
application of interface design where you need constant feedback and
rapid-turnaround.