[Laszlo-dev] For Review: Change 20080209-dda-7 Summary: SWF9 mixin support

[Donald Anderson]

On Feb 10, 2008, at 1:57 PM, P T Withington wrote:

> This looks great!  Approved.
>
> Comment: In Javascript, symbols begining with $ are supposed to be  
> reserved for internal implementation, so we really are within our  
> rights to use that.  If we really cared, we could escape user $ by  
> doubling them or something, but I don't see any reason to.

Yes.  But in our case, we are using name like Mixin$Super  (not  
starting with $) for the interstitial.
So a user with an embedded '$' (not as first character) could  
potentially conflict with
a generated class.  Should I be starting such generated class names  
with $,
perhaps something like $lzmixin$Mixin$Super ?
Then I'd be able to relax the rule to just disallow initial $.

- Don

> On 2008-02-09, at 14:28 EST, Donald Anderson wrote:
>
>> Change 20080209-dda-7 by dda at lester.local on 2008-02-09 13:57:38 EST
>>   in /Users/dda/laszlo/src/svn/openlaszlo/branches/devildog
>>   for http://svn.openlaszlo.org/openlaszlo/branches/devildog
>>
>> Summary: SWF9 mixin support
>>
>> New Features:
>>
>> Bugs Fixed: LPP-5266
>>
>> Technical Reviewer: ptw (pending)
>> QA Reviewer: promanik (pending)
>> Doc Reviewer: (pending)
>>
>> Documentation:
>>
>> Release Notes:
>>
>> Details:
>>   The mixin support follows the design given by Tucker in LPP-5266.
>>
>>   In SWF9Generator, when a mixin is seen, it is recorded in  
>> mixinDef hashmap.
>>   For each use of a mixin combination, the needed interstitials are  
>> recorded in
>>   the mixinRef hashmap, and all we need to do to the referencing  
>> class is change
>>   its superclass to be the interstitial.
>>
>>   Each mixin declaration AST is duplicated - one is processed
>>   like a class and one like an interface.   
>> (CommonGenerator:translateClassDirectivesBlock
>>   now knows three ways to process a class - the third being to  
>> create a property list).
>>   The 'interface' version of the mixin remains in the parse tree  
>> and is emitted
>>   as the interface.  The 'class' version of the mixin is what is  
>> put into mixinDef.
>>
>>   After we are done processing the AST, we visit the mixinRef map  
>> and for each entry,
>>   we append a new class to the parse tree that implements the  
>> interstitial.
>>
>>   In unparsing, we need to track the current class name, since  
>> constructors within
>>   interstitials need that as their name (and not their original  
>> name which matches
>>   the mixin).  Arguably this could be handled when the tree is  
>> created, but currently
>>   we are sharing all the contents of the interstitial AST with  
>> possibly other interstitials.
>>   Also in unparsing, bodies of functions for interfaces are handled  
>> differently, so
>>   we must track when we are in an interface.
>>
>>   The changes only affect the implementation of mixins for SWF9.   
>> It should be
>>   possible to push this implementation into generic javascript  
>> eventually.
>>   That seemed too big for this moment.
>>
>> Tests:
>>   regression tests: smoke/lzpix/weather for DHTML, SWF8 and henry's  
>> hello for SWF9
>>   mixin tests: for this, verified they compiled and checked  
>> contents by eye.
>>     constructors in mixins
>>     public/private methods in mixins
>>     vars in mixins
>>     mixins can appear after usage
>>     overridden methods possible
>>     multiple mixins
>>   Not yet tested - converting LFC9 classes back to use mixins.
>>
>> Files:
>> M      WEB-INF/lps/server/src/org/openlaszlo/sc/SWF9Generator.java
>> M      WEB-INF/lps/server/src/org/openlaszlo/sc/CommonGenerator.java
>> M      WEB-INF/lps/server/src/org/openlaszlo/sc/ 
>> SWF9ParseTreePrinter.java
>> M      WEB-INF/lps/server/src/org/openlaszlo/sc/Compiler.java
>> M      WEB-INF/lps/server/src/org/openlaszlo/sc/ParseTreePrinter.java
>> M      WEB-INF/lps/server/sc/src/org/openlaszlo/sc/parser/ 
>> ASTIdentifier.java
>>
>> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080209-dda-7.tar
>>
>>
>>
>> --
>>
>> Don Anderson
>> Java/C/C++, Berkeley DB, systems consultant
>>
>> voice: 617-547-7881
>> email: dda at ddanderson.com
>> www: http://www.ddanderson.com
>>
>>
>>
>>
>


--

Don Anderson
Java/C/C++, Berkeley DB, systems consultant

voice: 617-547-7881
email: dda at ddanderson.com
www: http://www.ddanderson.com