On 2010-05-10, at 15:25, André Bargull wrote: > 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.
Great! > 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. Correct. We should probably give a warning saying that `final` is not permitted on class-allocated properties (or that it doesn't do what you are thinking it might). >> 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. Good. Nice to avoid that complexity for now.
