I guess I like moving to 'interface' as a tag, while we have the chance. Having to explain 'traits' in tag world but 'interfaces with implementation' in the script world feels overly-complex to me.
I do like the idea of using the implements clause instead of extends- becomes-a-list. jim On Sep 14, 2006, at 9:10 AM, P T Withington wrote: > I am ambivalent as to whether we should use our preferred tag and > say that it translates to as JS1+ `interface`, or we should use > interface as our tag name too. > > I was about to say we should convey to ECMA the idea of letting > extends be a list, but perhaps since we hijacked interface we > should just list the trait/interfaces in the implements clause > (which is not yet implemented in our parser LPP-2686). I guess our > proposal boils down to letting you put common implementation into > the interface. You could permit partial implementations and the > compiler could complain if there are functions declared in the > interface that are not defined in either the interface or the class. > > On 2006-09-14, at 11:56 EDT, Jim Grandy wrote: > >> Great! I was going to propose that you do exactly this. >> >> Should we change our LZX tag name to suit? >> >> Any details that we should communicate back to ECMA in case they >> decide to implement interfaces with implementation? >> >> jim >> >> On Sep 14, 2006, at 4:11 AM, P T Withington wrote: >> >>> Change change.GBQ162YZu.txt by [EMAIL PROTECTED] /Users/ptw/ >>> pending-changes/ on 2006-09-14 06:47:35 EDT >>> >>> Summary: Implement LZS 'traits syntax', directive blocks in class >>> declarations >>> >>> New Features: >>> The LZS compiler now supports `interface` declarations, with the >>> extension that you are allowed to include implementation in an >>> interface. This is how you define a `trait` in lzs. >>> >>> Bugs Fixed: >>> LPP-2396 lzs syntax for trait declarations >>> LPP-2399 Allow directive blocks in class declarations >>> >>> Technical Reviewer: promanik (pending) >>> QA Reviewer: henry (pending) >>> Doc Reviewer: jsundman (pending) >>> >>> Documentation: >>> >>> .lzs source (LaszloScript, our variant of ECMAScript 1+) now >>> supports >>> class and interface declarations, as proposed by ECMAScript 2. We >>> permit implementation in interfaces, as has been proposed to the >>> ECMA >>> committee. Finally, the class `extends` clause can be a list, >>> consisting of a superclass and any number of interfaces, whose >>> implementation will be 'mixed in'. >>> >>> Details: >>> LzNode: moved `if ($debug)` back to their original position, >>> inside the class declaration. >>> >>> LzDataElement: re-wrote LzDataElementTrait as an `interface` >>> declaration. >>> >>> Parser.jjt: support for `interface` declarations, directives in >>> class and interface declarations. >>> >>> JavascriptGenerator, CodeGenerator: Move class clause processing >>> out to a subroutine that can recurse when encountering a >>> directive >>> block, conditional block or pragma. Make generic for class or >>> interface. >>> >>> Tests: >>> Changed two LFC files to use interface declarations and directive >>> blocks in class declarations. Inspected the output of the dhtml >>> compiler for accuracy. >>> >>> ant make, ant test, and LZPIX all functional. >>> >>> Files: >>> M lfc/core/LzNode.lzs >>> M lfc/data/LzDataElement.lzs >>> M server/sc/src/org/openlaszlo/sc/Parser.jjt >>> M server/src/org/openlaszlo/sc/Compiler.java >>> M server/src/org/openlaszlo/sc/JavascriptGenerator.java >>> M server/src/org/openlaszlo/sc/CodeGenerator.java >>> >>> <patch.ptw.V9Py.tgz> >>> >>> _______________________________________________ >>> Laszlo-dev mailing list >>> [email protected] >>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev >> >> >> _______________________________________________ >> Laszlo-dev mailing list >> [email protected] >> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
