LZX -> Javascript is not a straight through mapping. LZX is a more powerful
language than Javascript (although we try to keep the mapping close so that it
is easier for us to bootstrap -- write the lfc. This is why there is an
improvement out there to create a JS syntax for writing constraints).
I purposely used `allocation='class'` in LZX because I think `static`, as
defined in C++ and embraced by its many descendants, is broken. So we have
flexibility on how we map that to Javascript (and to any underlying platform
runtime).
My intention was that `allocation='class'` is a way when creating a new class
(which is itself an instance of the class <class>) to add properties to your
class-instance (as opposed to defining properties that will be properties of
each object created by your class). So, yes, if I declared such a property to
be final in <class> itself, I would mean that subclasses of <class>,
user-defined classes, could not override that property.
We could go off the deep end here and define a whole meta-object protocol for
LZX, but I don't think we need to.
On 2010-05-08, at 19:31, André Bargull wrote:
> I read that method declaration as 'static final function apply () { ... }'
> (in LZS syntax). But what our semantics for a static, final function? Is it
> Java-like, so you disallow subclasses from redeclaring the function. Or is it
> ActionScrip3-like, that means it isn't even allowed to declare such a
> function (you get this warning in AS3 if you try to make a function both
> final and static: "The attribute final can only be used on a method defined
> in a class"). The current ES-Harmony strawman for classes doesn't include
> inheritance, so no chance to make a 100% compatible decision which is in
> accordance with a future EcmaScript version.
>
>
> On 5/8/2010 10:40 PM, P T Withington wrote:
>> Yes, you are right, only class methods are a problem, so the schema really
>> should say:
>>
>> <method name="apply" allocation="class" final="true" />
>>
>> etc.
>>
>> The listing in lfc-undeclared seems to a pretty random collection.
>>
>> On 2010-05-08, at 16:28, André Bargull wrote:
>>
>>> No,<state>#apply() and<state>#remove() aren't deprecated. They were
>>> proposed to be deprecated, but the proposal wasn't accepted.
>>>
>>> apply() and call() as 'instance' methods could be allowed, only 'class'
>>> methods are problematic, right?
>>>
>>>
>>> On 5/8/2010 10:15 PM, P T Withington wrote:
>>>> Isn't LzState/apply deprecated? I thought you were supposed to constrain
>>>> `applied` instead?
>>>>
>>>> In which case, we could keep the warning.
>>>>
>>>> I agree with Henry, we were trying to help people. If you clobber
>>>> apply/call, you could regret it later...
>>>>
>>>> On 2010-05-08, at 11:27, André Bargull wrote:
>>>>
>>>>> Both, "apply" and "call" are marked as final in lfc-undeclared.xml, is
>>>>> there any reason for this decision? I know this question was already
>>>>> raised in an earlier thread.
>>>>> I'm working on LPP-8982, LPP-8983 and LPP-8986 and I think I've found a
>>>>> way to fix these bugs, but unfortunately compiling an application will
>>>>> now result in a compiler warning caused by<state>#apply():
>>>>>> trunk/WEB-INF/lps/schema/lfc.lzx:509:42: Method state.apply is
>>>>>> overriding a superclass method of the same name which has been declared
>>>>>> final
>>>>>
>>>>> The compiler warning is actually correct, if apply() is final it should
>>>>> not be possible to declare a method named "apply" in<state>. So, should I
>>>>> just remove those annotations from lfc-undeclared or add an ugly
>>>>> workaround to the compiler or ...?
>>>>>
>>>>>
>>>>> - André
>>>>>
>>>>
>>>>
>>
>>
