Well, that's kind of what we're discussing now.
The idea of an 'interface' is in the ES4 (ECMAScript Release 4) draft
materials, but without the ability to add implementation. Interfaces
are the similar to the Java concept of the same name, or to IDL
(interface description language) -- they specify what methods a class
is required to have. Our addition is to say that interfaces can also
have implementation -- they can contain methods and attributes of
their own -- which makes them basically identical to what we've been
calling 'traits'.
The nice thing about this is that rather than introducing a new
language construct ("traits") that few people have heard of and that
we have to describe ourselves, we are extending an existing language
construct ("interfaces") which is already available in ActionScript 2
and 3 and is being proposed for inclusion in the ECMAScript standard.
The extension isn't minor, but we're much better aligned with what
people are already learning so acceptance should be easier.
jim
On Sep 14, 2006, at 10:41 AM, John Sundman wrote:
> I was just talking to Tucker about this. I asked, "is there an
> official JavaScript definition of 'interface', and if so are we
> implementing it or are we extending it?
>
> Tucker's answer was, if I recall correctly, "I don't know, and
> we're 'embracing and extending'."
>
> Any comment? I'm trying to understand how much of this whole
> subject is standard ECMAscritpt, for which I can rely on external
> sources, and how much is new to LZX that I'll have to explain
> entirely.
>
> jrs
>
> On Sep 14, 2006, at 1:06 PM, Jim Grandy wrote:
>
>> 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
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
