Here is another sequence that might not be too bad::<
var x = proto :< {a:1, b:2};
or :<=
Courier
proto :< {a:1, b:2}
Courier new
proto :< {a:1, b:2}
Menlo
proto :< {a:1, b:2}
Monaco
proto :< {a:1, b:2}
Lucida console
proto :< {a:1, b:2}
Comic Sans
proto :< {a:1, b:2}
__
On 21 May 2011 01:16, felix wrote:
> how about the fish operator <><, easy to type.
Whow, apparently, you are not cursed with a German keyboard. ;)
Seriously, "easy to type" is an argument that is highly subjective to
i18n-related concerns. The majority of JS programmers does not have
English ke
On Fri, May 20, 2011 at 14:46, Brendan Eich wrote:
>> <~ has the disadvantage that it looks somewhat similar to <- and thus ->
>
> <~ and <- are not backward-compatible extensions, consider function test(a,b)
> { return a<-b; }.
how about the fish operator <><, easy to type.
it clashes with e4x
On May 20, 2011, at 2:32 PM, Sean Eagan wrote:
> <: kind of looks like a jet with two rocket engines on the back which
> might be memorable. It could be called the "jet operator" or "rocket
> operator".
On some fonts it looks pretty bad, though.
> <~ has the disadvantage that it looks somewhat
To me, the lighter weight of ~ and : make them more contextually
visually distinct than | next to object, array, and regexp literal
brackets [ { /
<: kind of looks like a jet with two rocket engines on the back which
might be memorable. It could be called the "jet operator" or "rocket
operator".
It's okay in Courier New but not in lots of other popular monospaced fonts. See
attached image.
Dave
<>
On May 18, 2011, at 3:30 PM, Allen Wirfs-Brock wrote:
>
> On May 18, 2011, at 3:14 PM, David Herman wrote:
>
>>> I think I like <: about as much as <|. I'm not sure which is going to be
On May 18, 2011, at 3:14 PM, David Herman wrote:
>> 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 just have to say that the pipe symbol in many font
> 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 just have to say that the pipe symbol in many fonts makes for a really
hideous triangle. It doesn't line up
The rationale for the arrow pointing the way the proto-link points was also in
the very message Bob cited :-P.
"Triangle man, Triangle man
Triangle man hates particle man
They have a fight, Triangle wins
Triangle man"
(Some think this is about world religions, others say physics. I say OOP.)
/b
On May 18, 2011, at 11:30 AM, Bob Nystrom wrote:
> What about making the operator go in the other direction, like so:
>
>
My rationale for the ordering is explained in the third bullet of the
"Commentary and rationales" section of the proposal
http://wiki.ecmascript.org/doku.php?id=strawman:
What about making the operator go in the other direction, like so:
{a:1,b:2} |> MyObject.prototype
[0,1,2,3,4,5] |> appBehavior
Array.create=function(proto,props) {
return Object.defineProperties([ ] |> proto, props)
};
let f = function () {} |> EnhancedFunctionPrototype
var p = /[a-m][3-7]/
Allen Wirfs-Brock 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.
On 11:59 AM, Allen Wirfs-Brock wrote:
class hierarchy diagrams are only useful for understanding designs when you
actually have complex hierarchies. This very conversation is about adding
features to make it easy for JS programmers to build such hierarchies. Who
knows, may e in a few years we
On May 18, 2011, at 10:30 AM, Allen Wirfs-Brock wrote:
> On May 18, 2011, at 9:52 AM, Brendan Eich 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 go
On May 18, 2011, at 9:52 AM, Brendan Eich 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, i
On May 18, 2011, at 9:51 AM, Brendan Eich wrote:
> 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
On Wed, May 18, 2011 at 10:10 AM, Brendan Eich wrote:
> On May 18, 2011, at 10:07 AM, Mark S. Miller wrote:
>
> > 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 sh
On May 18, 2011, at 10:07 AM, Mark S. Miller wrote:
> 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.
Do you m
On Wed, May 18, 2011 at 9:52 AM, Brendan Eich 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,
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 learnabil
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 re
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
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 *tooli
On Wed, May 18, 2011 at 11:53 AM, Allen Wirfs-Brock
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 use
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
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
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
On May 18, 2011, at 6:46 AM, Sam Tobin-Hochstadt wrote:
> On Wed, May 18, 2011 at 2:59 AM, Luke Hoban 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 se
On Wed, May 18, 2011 at 2:59 AM, Luke Hoban 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
>>> any
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.
Thi
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
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_ope
>> 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
> 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
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
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. Bu
uke
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Allen Wirfs-Brock
Sent: Tuesday, May 17, 2011 7:50 PM
To: es-discuss@mozilla.org
Subject: prototype for operator proposal for review
We had so much fun with feedback on my Unicode proposal I just have o
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___
38 matches
Mail list logo
