On 5/9/2010 3:11 PM, P T Withington wrote:
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.
I've tested this and it seems to work pretty well with my other changes.
Thanks!
I'll try to create a few test cases to cover more variations of
'allocation' and 'final' before sending a change set for review.
Concerning LPP-8986 (Overriding final static method generates compiler
warning):
A method with `allocation='class'` and `final='true'` shouldn't be
allowed at all, should it? I don't see any reason to make a method final
to prohibit re-definition if it isn't even possible to perform such a
re-definition.
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.
No, not yet required.
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é
