Exemplar forms (was Your search - "|>" - did not match any documents)

Jake Verbaten raynos2 at gmail.com
Fri Oct 14 10:12:49 PDT 2011


On Fri, Oct 14, 2011 at 5:54 PM, John J Barton
<johnjbarton at johnjbarton.com>wrote:

>
>
> On Thu, Oct 13, 2011 at 4:14 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>
>> Let me take a crack at tying to tie together all the pieces we have been
>> talking about.
>>
>>
> Allen, I really appreciate your synthesis, thanks. I am able to follow some
> of it because of my recent Q/A with the group. I think many more people
> would be able to follow it if the approximate semantics of new features
> where readily accessible. Maybe just an parenthetical explanation and a link
> to the strawman page (these are pretty daunting however).
>
>
I believe the following links may aid in explaining some of the content

 - ES:Harmony Object Literals
syntax<http://wiki.ecmascript.org/doku.php?id=harmony:object_literals>
 - Axel's prototypes as classes
article<http://www.2ality.com/2011/06/prototypes-as-classes.html>


> <lots of interesting text elided>
>
>
>>
>> This is a more complicated tory then simply having a traditional class
>> model such as Dart is using.  However, we have an existing language with
>> existing featuures with a wide range of usages patterns so whatever we do
>> with "classes" we still have to accommodate what currently exists in JS. We
>> are never going to have as simple a story as a do-over language such as
>> Dart. But I do think we can craft a understandable story where all the
>> pieces fit together relatively nicely.
>>
>
> I really like this perspective, with two caveats:
>
> 1) To achieve the goal of "Keep the language pleasant for casual
> developers.", the correspondence between JS and traditional class models
> needs to be real, clear, and communicated well. Points of disconnect need to
> be ironed out.  The danger of saying "class" and meaning something different
> are great but the dangers of saying Grawlix include no one caring about the
> meaning.
>
> 2) Your proposal is dominated by declarative syntax for objects, in
> contrast to practice which uses functions to construct objects. Of course it
> is possible that your new features would obsolete that practice, but I doubt
> it. By design the declarative syntax creates limits on objects that are
> simple to overcome with direct manipulation.
>

I believe the use of declarative syntax is to get semantics across in a
terse well specified manner. All of his declarative syntax has existing
alternatives available we can use currently using methods. I don't think any
of the declarative syntax has limits.


>
> jjb
>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111014/01f4ad1e/attachment.html>


More information about the es-discuss mailing list