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
