I was sloppy in my description.
In LZX, you have never been able to add a method at runtime. LZX is a
declarative language. [There was some confusion in the past that <state>
allowed to to add or remove methods from a node, but that was not the design,
just an accident of implementation.
In JS, there is no such thing as a method, so you can't add or remove methods
at runtime there either.
In AS3, there are classes and methods and you are not allowed to add or remove
methods at runtime there either.
AS3 is a blend of JS with classes and methods, and method lookup is blurred
with property lookup, so you can have the illusion of adding a method to an
instance if you have a dynamic instance and add a new function-valued property
to that instance. You may even give yourself the illusion that you have added
a method, because of the way JS passes `this` as an invisible parameter to
functions when they are invoked using `object.function()`. Nevertheless, this
function-valued attribute is _not_ a method in the true sense. Here is an
example demonstrating the difference:
> <canvas debug="true">
> <script when="immediate">
> dynamic class foo {
> var value = 42;
> function methodvalue () { return this.value; }
> };
> var example = new foo();
> example.functionvalue = function () { return this.value; }
> var mv = example.methodvalue;
> var fv = example.functionvalue;
> Debug.write("Method value: %w\n", mv());
> Debug.write("Function value: %w\n", fv());
> </script>
> </canvas>
This example only works correctly in SWF10/AS3, where there are true methods.
There the output is:
> Method value: 42
> Function value: (void 0)
I hope this illustrates the difference I am drawing between a function and a
method clearly.
Finally, the point I was making about the Flex compiler, because it implements
AS3, with its blend of JS and classes, it cannot at compile time determine that
there is a missing method, because the syntax for a method call and for calling
a function-valued property are the same, and if the instance class is dynamic,
function-valued properties can be added at runtime.
If we were to make LZX more strict and not allow adding properties to instances
at runtime, we could make our classes sealed, and then the compiler could be
more helpful. Currently the feeling is that that would be too radical a change
in LZX semantics.
OTOH, since you can _not_ add LZX methods at run time, the LZX compiler _could_
determine that the base method is missing in Phil's test case. Making this
determination will be easier once Don has finished his current project, which
is to more carefully model classes in the compiler, and to store these models
in a way that they can be re-read when linking a user application to the LFC.
On 2011-01-28, at 08:50, Raju Bitter wrote:
> Tucker, what is the reason that methods cannot be added at runtime any more?
>
> On Tue, Jan 25, 2011 at 1:43 AM, P T Withington <[email protected]> wrote:
>
>> [Did your debugger not warn you to install the Flash Debug player? It's a
>> bug if it did now.
>>
>> If you had the Debug player, you would have gotten a slightly more useful
>> error message:
>>
>>> ERROR @phil.lzx#10: ReferenceError: Error #1070: Method draw not found on
>> LzView
>>> drawmixin1.draw init
>>> myclass.draw init
>>
>> ]
>>
>> Ok, this is because of the dynamic nature of LZX. In the past, you _could_
>> add a draw method to lz.view at runtime, which is why no one complains,
>> including the normally strict Flex compiler.
>>
>> But, we have new rules now, that say you no longer can add methods at
>> runtime (but unfortunately, we still let you add other things, so we can't
>> ask Flex to be that strict, yet).
>>
>> Could you file an improvement to detect this at runtime? It should be
>> pretty easy to do once Don has the class models working. The compiler
>> already has most of the information it needs to make this check, since it
>> already has to auto-compute when an LZX method needs `override`, it just
>> needs to complain if it sees a super() call without an override.
>>
>> In the mean time, the mixin user needs to either be an expert, or wear
>> safety glasses and steel-toed shoes.
>>
>> On 2011-01-24, at 19:26, [email protected] wrote:
>>
>>>
>>>
>>>> Also as I say in the wiki page, and I hope what I said is true, your
>> second example should fail to compile in the swf10 runtime. The Flex
>> compiler should notice that you are calling a non-existent super method at
>> compile time, and complain.
>>>
>>> There isn't a compile time error; just a runtime error.
>>>
>>> ERROR @c3.lzx≈10: ReferenceError: Error #1070
>>> drawmixin1.draw init
>>> myclass.draw init
>>>
>>>
>>> The HTML5 compile has a better error message:
>>>
>>> ERROR: super.draw is undefined in draw
>>> drawmixin2.draw init
>>> drawmixin1.draw init
>>> myclass.draw init
>>
>>
>>
