prototype for operator proposal for review

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

prototype for operator proposal for review

Allen Wirfs-Brock
We had so much fun with feedback on my Unicode proposal I just have open another one up for list feed back:

An updated version of the "prototype for" (formerly proto) operator proposal is at http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator 

Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: prototype for operator proposal for review

Luke Hoban

If there were a more usable library variant of Object.create instead, it seems the new syntax here would not be as necessary.

 

Instead of:

  var  o = myProto <| {

       a: 0,

       b: function () {}

  }

 

You could do:

  var  o = Object.make(myProto, {

       a: 0,

       b: function () {}

  })

 

A few more characters, but still addresses the major issue preventing wider Object.create usage (the use of property descriptors).  A library solution also keeps the benefit of not needing new syntax, and being available to text/javascript.  As noted in the strawman, similar functions on Array and Function could support the other scenarios described in the proposal.

 

It seems the syntax is perhaps aiming to avoid needing to allocate an intermediate object – but I imagine engines could potentially do that for Object.make and friends as well if it was important for performance?

 

Luke

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Allen Wirfs-Brock
Sent: Tuesday, May 17, 2011 7:50 PM
To: [hidden email]
Subject: prototype for operator proposal for review

 

We had so much fun with feedback on my Unicode proposal I just have open another one up for list feed back:

 

An updated version of the "prototype for" (formerly proto) operator proposal is at http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator 

 

Allen


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Jeff Walden-6
On 05/17/2011 09:49 PM, Luke Hoban wrote:
> It seems the syntax is perhaps aiming to avoid needing to allocate an intermediate object – but I imagine engines could potentially do that for Object.make and friends as well if it was important for performance?

It's probably possible to do that.  But such hacks are rather fragile.  I suspect this would take roughly the form of the way SpiderMonkey optimizes Function.prototype.apply, which is roughly to look for calls of properties named "apply" and do special-case behavior with a PIC in the case that that property is actually |Function.prototype.apply|.  It takes some pretty gnarly code, duplicated two places (possibly a third, but that might not be necessary), to make it all happen.  That sort of pattern certainly can be repeated if push comes to shove.  But I believe doing so is far inferior to dedicated, first-class syntactical support to make the semantics absolutely unambiguous and un-confusable with anything else.

In this particular case, I suspect implementing a PIC that way would be even gnarlier, because it wouldn't just be a PIC on the identity of the |Object.make| property, it'd have to also apply to computation of the arguments provided in the function "call" (or a not-call if you're using a PIC this way).  That too can probably be done.  But it'd be pretty tricky (thinking of things like the PIC only being applicable if the argument is an object literal, and of it being mostly inapplicable if it's anything else).  And if you wanted to extend that to apply to more functions than just a single Object.make function, the hacks will be even more complex, possibly not even by a constant increment.

And of course this would also make it harder for IDEs and such to give good first-class syntax highlighting here, because the syntax for this would be ambiguous with user-created stuff.

Anyway, food for thought.  And I know others here are more familiar with this than I am, so please chime in with more if you have it, or corrections if you have them.

Jeff
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Allen Wirfs-Brock
In reply to this post by Luke Hoban
<base href="x-msg://1952/">
On May 17, 2011, at 9:49 PM, Luke Hoban wrote:

If there were a more usable library variant of Object.create instead, it seems the new syntax here would not be as necessary.
 
Instead of:
  var  o = myProto <| {
       a: 0,
       b: function () {}
  }
 
You could do:
  var  o = Object.make(myProto, {
       a: 0,
       b: function () {}
  })
 
A few more characters, but still addresses the major issue preventing wider Object.create usage (the use of property descriptors).  A library solution also keeps the benefit of not needing new syntax, and being available to text/javascript.  As noted in the strawman, similar functions on Array and Function could support the other scenarios described in the proposal.

That isn't really what this proposal is about, but it is what the http://wiki.ecmascript.org/doku.php?id=strawman:concise_object_literal_extensions proposal addresses. 

The primary scenario is what some people call "subclassing" the various built-in classes of objects that have special internal state and behavior. The most important of these "classes" are Array, Function, and RegExp.  Programmer want to be able to create instances of these whose direct [[Prototype]] is different from the default. (in most cases the desired prototype will inherit from the default)

Specifying the prototype for an object literal  is also a scenario but I wouldn't necessarily say it is more important than the other.

 
It seems the syntax is perhaps aiming to avoid needing to allocate an intermediate object – but I imagine engines could potentially do that for Object.make and friends as well if it was important for performance?

An implementation might try to optimize such functions as you describe, but because both the global binding to the base  object and the property binding of the method are mutable you at least have to have a dynamic guard on any fast path and still have to generate the code to create the arguments and do a regular call if the guard fails.  I made the same argument for Object.create and I'm not aware of implementation that have yet to optimize it in this manner.

Another difference from the function approach is that the function can assume it is being passed a new object or even any object of the kind it is expect. The <| ooperator is syntactically required in the current proposal to have a literal form as its right operand so both implementations and human code readers can determine by examination what [[Class]] of object is being created.


Allen

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: prototype for operator proposal for review

Luke Hoban
> The primary scenario is what some people call "subclassing" the various built-in classes of objects that have special internal state and behavior. The most important of these "classes" are Array, Function, and RegExp.  Programmer want to be able to create instances of these whose direct [[Prototype]] is different from the default. (in most cases the desired prototype will inherit from the default)

I was assuming that similar library functions such as Array.make, Function.make and RegExp.make would address these cases in the same way as Object.make.  Beyond the intermediate object allocation issue, is there anything else those cannot accomplish?  Either way, exposing the library function alternatives as well seems useful to provide the capability to subclass these objects in 'text/javascript'.



> An implementation might try to optimize such functions as you describe, but because both the global binding to the base  object and the property binding of the method are mutable you at least have to have a dynamic guard on any fast path and still have to generate the code to create the arguments and do a regular call if the guard fails.  I made the same argument for Object.create and I'm not aware of implementation that have yet to optimize it in this manner.

Fair enough.  I'll check on whether we have considered any similar optimizations in IE.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: prototype for operator proposal for review

Luke Hoban
In reply to this post by Jeff Walden-6
>> That sort of pattern certainly can be repeated if push comes to shove.  But I believe doing so is far inferior to dedicated, first-class syntactical support to make the semantics absolutely unambiguous and un-confusable with anything else.

This makes sense.  I just want to make sure that the fundamental capability to subclass built-in objects is available via libraries for text/javascript, with the new syntax offering the more performant option for text/harmony.



>> And of course this would also make it harder for IDEs and such to give good first-class syntax highlighting here, because the syntax for this would be ambiguous with user-created stuff.

What kind of syntax highlighting would you want to offer?  Distinguishing normal arrays from arrays with non-standard prototypes would be more difficult, but this doesn't seem like a common syntax highlighting need.  


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Dmitry Soshnikov
In reply to this post by Allen Wirfs-Brock
On 18.05.2011 6:50, Allen Wirfs-Brock wrote:
We had so much fun with feedback on my Unicode proposal I just have open another one up for list feed back:

An updated version of the "prototype for" (formerly proto) operator proposal is at http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator 


Just a small note on:

"There are many other possible special character alternates to <|. For example, |>, ^^, *>, &>, ^|, <|-, etc. It isn’t clear that any of these is more meaningful or mnemonic than <|."

Perhaps just "less than" would be enough? Why we need two symbols? It's by the way, a real implementation of subclassing in Ruby:

class Foo
  def alert
    p "Called from Foo class"
  end
end

class Bar < Foo
  def alert
    super
  end
end

bar = Bar.new
bar.alert # "Called from Foo class"

It sounds quite logical -- "by hierarchy Bar is *less than* Foo".

And also: what's happened to meta-properties in initialisers? It seems to me that having them we get also the ability not only to specify the proto, but also other control attributes for properties and to the object. And since #-symbol has changed its semantics, and instead ->-functions (or probably Ruby's blocks) are on agenda instead, maybe we may use # exactly for meta properties?

let foo = {x: 10};

let bar = {

  #proto: foo,
  #closed

  y: 20,
  // etc.

};

Dmitry.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Dmitry Soshnikov
Besides. The same inheriting keyword can be used for both -- classes inheriting and just classless (or chaotic, prototypal) reuse:

foo < bar

class Foo < Bar

or

foo extends bar {
  y: 20
}

class Foo extends Bar

Since both implements the same pattern -- linear vertical "tower" of code reuse (in simple words -- just single inheritance), then the same keyword seems also logical.

Dmitry.

On 18.05.2011 11:41, Dmitry A. Soshnikov wrote:
On 18.05.2011 6:50, Allen Wirfs-Brock wrote:
We had so much fun with feedback on my Unicode proposal I just have open another one up for list feed back:

An updated version of the "prototype for" (formerly proto) operator proposal is at http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator 


Just a small note on:

"There are many other possible special character alternates to <|. For example, |>, ^^, *>, &>, ^|, <|-, etc. It isn’t clear that any of these is more meaningful or mnemonic than <|."

Perhaps just "less than" would be enough? Why we need two symbols? It's by the way, a real implementation of subclassing in Ruby:

class Foo
  def alert
    p "Called from Foo class"
  end
end

class Bar < Foo
  def alert
    super
  end
end

bar = Bar.new
bar.alert # "Called from Foo class"

It sounds quite logical -- "by hierarchy Bar is *less than* Foo".

And also: what's happened to meta-properties in initialisers? It seems to me that having them we get also the ability not only to specify the proto, but also other control attributes for properties and to the object. And since #-symbol has changed its semantics, and instead ->-functions (or probably Ruby's blocks) are on agenda instead, maybe we may use # exactly for meta properties?

let foo = {x: 10};

let bar = {

  #proto: foo,
  #closed

  y: 20,
  // etc.

};

Dmitry.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Kyle Simpson
In reply to this post by Luke Hoban
I'm definitely in favor of this <| proposal, btw.

>>> That sort of pattern certainly can be repeated if push comes to shove.
>>> But I believe doing so is far inferior to dedicated, first-class
>>> syntactical support to make the semantics absolutely unambiguous and
>>> un-confusable with anything else.
>
> This makes sense.  I just want to make sure that the fundamental
> capability to subclass built-in objects is available via libraries for
> text/javascript, with the new syntax offering the more performant option
> for text/harmony.

I'm pretty sure current `text/javascript` can sub-class safely, as FuseBox
(from @fusejs) does with sandboxing natives. It's hacky, and relies on the
non-standard __proto__ in most browsers (iframe in others), but it IS
possible. Perhaps we should still formalize it, if we think
`text/javascript` is gonna be around for a long time in parallel with
ES.Next that has something like <|.


--Kyle

 

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Sam Tobin-Hochstadt
In reply to this post by Luke Hoban
On Wed, May 18, 2011 at 2:59 AM, Luke Hoban <[hidden email]> wrote:
>>> That sort of pattern certainly can be repeated if push comes to shove.  But I believe doing so is far inferior to dedicated, first-class syntactical support to make the semantics absolutely unambiguous and un-confusable with anything else.
>
> This makes sense.  I just want to make sure that the fundamental capability to subclass built-in objects is available via libraries for text/javascript, with the new syntax offering the more performant option for text/harmony.

Perhaps I'm missing something, but <| seems like something that could
be provided to 'text/javascript' just as easily as
'text/the-next-javascript'.  Unlike using |module| as a keyword, or
changing the scope rules or |typeof null|, no working
'text/javascript' program uses <| at the moment.
--
sam th
[hidden email]
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Brendan Eich-3
On May 18, 2011, at 6:46 AM, Sam Tobin-Hochstadt wrote:

> On Wed, May 18, 2011 at 2:59 AM, Luke Hoban <[hidden email]> wrote:
>>>> That sort of pattern certainly can be repeated if push comes to shove.  But I believe doing so is far inferior to dedicated, first-class syntactical support to make the semantics absolutely unambiguous and un-confusable with anything else.
>>
>> This makes sense.  I just want to make sure that the fundamental capability to subclass built-in objects is available via libraries for text/javascript, with the new syntax offering the more performant option for text/harmony.
>
> Perhaps I'm missing something, but <| seems like something that could
> be provided to 'text/javascript' just as easily as
> 'text/the-next-javascript'.  Unlike using |module| as a keyword, or
> changing the scope rules or |typeof null|, no working
> 'text/javascript' program uses <| at the moment.

Couple of small points, one I already laid on Luke in a private reply:

1. text/javascript is unregistered HTML4 noise. RFC4329 has application/javascript and application/ecmascript with version parameter reserved.

2. Developers want new syntax not to choke old browsers. I've been there in 1996-2001 with ES2 and ES3. So using a new type or version value hides the new syntax from old browsers. You have to do something for the old browsers, of course, either server-side or client-side. See

http://wiki.ecmascript.org/doku.php?id=strawman:versioning

and its links. I'm going to improve this page shortly.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Allen Wirfs-Brock
In reply to this post by Luke Hoban

On May 17, 2011, at 11:59 PM, Luke Hoban wrote:

>>>
>>> And of course this would also make it harder for IDEs and such to give good first-class syntax highlighting here, because the syntax for this would be ambiguous with user-created stuff.
>
> What kind of syntax highlighting would you want to offer?  Distinguishing normal arrays from arrays with non-standard prototypes would be more difficult, but this doesn't seem like a common syntax highlighting need.  
>

In general declarative constructs are easier for tools to analyze than imperative processes built out of function calls.  All the complications that were brought up for optimizing the imperative forms also apply to tools and tools don't have any dynamic context available to verify any inferences they may make.  This applies to more than just syntax highlighters.  Refactoring tools, reference engineering tools, and anything else that wants to statically source code generally will have an easer time with declarative constructs.

Allen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Allen Wirfs-Brock
In reply to this post by Dmitry Soshnikov

On May 18, 2011, at 12:41 AM, Dmitry A. Soshnikov wrote:

On 18.05.2011 6:50, Allen Wirfs-Brock wrote:
We had so much fun with feedback on my Unicode proposal I just have open another one up for list feed back:

An updated version of the "prototype for" (formerly proto) operator proposal is at http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator 


Just a small note on:

"There are many other possible special character alternates to <|. For example, |>, ^^, *>, &>, ^|, <|-, etc. It isn’t clear that any of these is more meaningful or mnemonic than <|."

Perhaps just "less than" would be enough? Why we need two symbols? It's by the way, a real implementation of subclassing in Ruby:



< already has a meaning for operands that are arbitrary objects.  It applies valueOf and/or toString to the operands and then compares the results.


And also: what's happened to meta-properties in initialisers? It seems to me that having them we get also the ability not only to specify the proto, but also other control attributes for properties and to the object. And since #-symbol has changed its semantics, and instead ->-functions (or probably Ruby's blocks) are on agenda instead, maybe we may use # exactly for meta properties?


The most common use case for meta properties was to set [[Prototype]].  That solution worked for object literals and array literal but didn't extend to functions, regexps, or other literal forms.  <| does.  The other uses of meta properties sealed, frozen, closed would probably be used infrequently enough that the Object functions are good enough:

      let bar = Object.preventExtensions(foo <| {y:20});

Also there were some concerns about possible syntactic conflicts between the proposed meta-property syntax and E4X features (I know...but some people care)...

Overall, <| seems like a simpler solution that is more general for the most important use case.

Allen



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Brendan Eich-3
On May 18, 2011, at 9:10 AM, Allen Wirfs-Brock wrote:

On May 18, 2011, at 12:41 AM, Dmitry A. Soshnikov wrote:

On 18.05.2011 6:50, Allen Wirfs-Brock wrote:
We had so much fun with feedback on my Unicode proposal I just have open another one up for list feed back:

An updated version of the "prototype for" (formerly proto) operator proposal is at http://wiki.ecmascript.org/doku.php?id=strawman:proto_operator 


Just a small note on:

"There are many other possible special character alternates to <|. For example, |>, ^^, *>, &>, ^|, <|-, etc. It isn’t clear that any of these is more meaningful or mnemonic than <|."

Perhaps just "less than" would be enough? Why we need two symbols? It's by the way, a real implementation of subclassing in Ruby:

< already has a meaning for operands that are arbitrary objects.  It applies valueOf and/or toString to the operands and then compares the results.

Indeed :-P -- see http://github.com/tobeytailor/def.js/blob/master//def.js and read the source.


Overall, <| seems like a simpler solution that is more general for the most important use case.

I like it, it's more general and it doesn't require guessing games by readers and optimizers about the meaning of "Object", "Object.make", etc.

The only thing that nags is the proto being on the left of the "triangle-arrow". Other languages and type theory use < or <: to put the extension or more-derived thing on the left, but here the extension (value not type, but still) is on the right.

Maybe I'll get over this, though. The use-case with an object literal as the extension really must be on the right, I quite agree. Does |> work any better?

/be


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Dean Landolt
In reply to this post by Allen Wirfs-Brock


On Wed, May 18, 2011 at 11:53 AM, Allen Wirfs-Brock <[hidden email]> wrote:

On May 17, 2011, at 11:59 PM, Luke Hoban wrote:

>>>
>>> And of course this would also make it harder for IDEs and such to give good first-class syntax highlighting here, because the syntax for this would be ambiguous with user-created stuff.
>
> What kind of syntax highlighting would you want to offer?  Distinguishing normal arrays from arrays with non-standard prototypes would be more difficult, but this doesn't seem like a common syntax highlighting need.
>

In general declarative constructs are easier for tools to analyze than imperative processes built out of function calls.  All the complications that were brought up for optimizing the imperative forms also apply to tools and tools don't have any dynamic context available to verify any inferences they may make.  This applies to more than just syntax highlighters.  Refactoring tools, reference engineering tools, and anything else that wants to statically source code generally will have an easer time with declarative constructs.


I think the argument for ease of static analysis applies just as well to human analysis (after all, our wetware makes for a poor interpreter). But I think the counter-argument is more compelling -- this is yet another construct our *tooling* would have to understand, and every new construct *substantially* ups the ante for fluency (ISTM the tax for each new syntax is approximately combinatorial for inexperienced developers).

The imperative alternative, on the other hand, only requires learning the semantics of a new API, not whole new constructs and how they compose (regardless of how nicely they compose). I personally believe this matters a great deal, and not just for newcomers. As I've heard /be suggest, some of javascript's success can be owed to its lack of syntactical novelty. I'm not saying all new syntax is bad syntax, but at the very least the committee should be optimizing for humans first.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Brendan Eich-3
On May 18, 2011, at 9:25 AM, Dean Landolt wrote:

> I think the argument for ease of static analysis applies just as well to human analysis (after all, our wetware makes for a poor interpreter). But I think the counter-argument is more compelling -- this is yet another construct our *tooling* would have to understand, and every new construct *substantially* ups the ante for fluency (ISTM the tax for each new syntax is approximately combinatorial for inexperienced developers).

I hear this sometimes, but not about languages with established syntactic complexity (e.g. Ruby). Indeed people learn Ruby and other languages by learning subsets. They learn via tutorials. They learn inductively until idioms need to be learned.

Meanwhile, syntax as better user interface, for usability ("developer ergonomics" applies to programming languages too), must matter. Not just keystrokes and chording for code production. That hurts (some of my RSI afflicted talented-programmer friends testify) but for *maintenance*.

And readability, which ultimately trumps writability but not in any zero-sum-game sense, can be aided by new syntax, compared to using library methods and functions.


> The imperative alternative, on the other hand, only requires learning the semantics of a new API, not whole new constructs and how they compose (regardless of how nicely they compose). I personally believe this matters a great deal, and not just for newcomers.

I don't see why you assume newcomers learn all the syntax, all at once. I did not when I learned a great many languages.


> As I've heard /be suggest, some of javascript's success can be owed to its lack of syntactical novelty. I'm not saying all new syntax is bad syntax, but at the very least the committee should be optimizing for humans first.

JS mainly had first-mover and it "did not suck" so badly that it lost to a second mover -- it stuck. We are not removing old syntax. So people can learn the old syntax if they like.

Then the objection moves from pedagogy to maintenance: "I don't want to have to maintain paren-free code", e.g. But you always have choices. Refuse, parenthesize were allowed, negotiate. Syntax is partly social.

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Allen Wirfs-Brock
In reply to this post by Brendan Eich-3

On May 18, 2011, at 9:20 AM, Brendan Eich wrote:

> The only thing that nags is the proto being on the left of the "triangle-arrow". Other languages and type theory use < or <: to put the extension or more-derived thing on the left, but here the extension (value not type, but still) is on the right.
>
> Maybe I'll get over this, though. The use-case with an object literal as the extension really must be on the right, I quite agree. Does |> work any better?
>

We probably could make :>  work (but, gag, typing this message on my Mac using Helvetica 12 the : is practically invisible next to >. <: doesn't seem to have quite the same problem for some reason).

I think I like <: about as much as  <|.  I'm not sure which is going to be more readable across a variety of fonts and sizes.  <| does seem to be generally more visually distinct.

I suspect that to most JS programmers the UML open triangle generalization arrow head is at least as relevant a precedent as any type theory uses.  In other words,the relevancy of either isn't very high.

One might argue that the prototype object is the more general and hence "smaller" object (the object on the right specializes the prototype by adding properties).

In the end, these are just symbols  and JS programmer are just going to have to learn their meaning. Existing conventions, if they exist, and analogous do impact initial learnability but in the long run I don't know if it makes much a difference as long as they aren't prone to keyboarding hazards.

Allen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Brendan Eich-3
On May 18, 2011, at 9:47 AM, Allen Wirfs-Brock wrote:

> I suspect that to most JS programmers the UML open triangle generalization arrow head is at least as relevant a precedent as any type theory uses.

I will take that bet. UML, ho ho! Maybe enterprise Java heads...


>  In other words,the relevancy of either isn't very high.

Perhaps not, but Ruby's < is relevant to a good-sized cohort.


> One might argue that the prototype object is the more general and hence "smaller" object (the object on the right specializes the prototype by adding properties).

Yes, type narrowness is a dual of object population in JS, if you think of object with properties as an exemplar (prototype, even) of a latent structural type.


> In the end, these are just symbols  and JS programmer are just going to have to learn their meaning. Existing conventions, if they exist, and analogous do impact initial learnability but in the long run I don't know if it makes much a difference as long as they aren't prone to keyboarding hazards.

The precedents matter a bit, even if we try to create a new idiom. The problem is < not | (although doesn't that look too light in Helvetica on either side?).

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Brendan Eich-3
On May 18, 2011, at 9:51 AM, Brendan Eich wrote:

> On May 18, 2011, at 9:47 AM, Allen Wirfs-Brock wrote:
>
>> In the end, these are just symbols  and JS programmer are just going to have to learn their meaning. Existing conventions, if they exist, and analogous do impact initial learnability but in the long run I don't know if it makes much a difference as long as they aren't prone to keyboarding hazards.
>
> The precedents matter a bit, even if we try to create a new idiom. The problem is < not | (although doesn't that look too light in Helvetica on either side?).

I don't think :> works, as you say. It looks like crap, frankly, in too many fonts. However, does |> not work?

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: prototype for operator proposal for review

Mark S. Miller-2


On Wed, May 18, 2011 at 9:52 AM, Brendan Eich <[hidden email]> wrote:
On May 18, 2011, at 9:51 AM, Brendan Eich wrote:

> On May 18, 2011, at 9:47 AM, Allen Wirfs-Brock wrote:
>
>> In the end, these are just symbols  and JS programmer are just going to have to learn their meaning. Existing conventions, if they exist, and analogous do impact initial learnability but in the long run I don't know if it makes much a difference as long as they aren't prone to keyboarding hazards.
>
> The precedents matter a bit, even if we try to create a new idiom. The problem is < not | (although doesn't that look too light in Helvetica on either side?).

I don't think :> works, as you say. It looks like crap, frankly, in too many fonts. However, does |> not work?

I made my peace with <| when Allen pointed out that the object on the left points at the object on the right. Flipping it around loses that mnemonic. This "points at" intuition should be independent of any prior exposure to UML.

 

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



--
    Cheers,
    --MarkM

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12