Allen Wirfs-Brock wrote:
> My comfort level in this starts to fall significantly as we get into the
> hit or miss space. That is the point it suddenly feels like it is trying
> to be (or should be trying to be) a complete meta-object protocol rather
> than just a reification of failed property acc
dan Eich
Cc: Allen Wirfs-Brock; es-discuss Steen
Subject: Re: Improving ECMAScript as a compilation target
All -
On May 6, 2009, at 1:15 AM, Brendan Eich wrote:
But obj.prop() is worth a catchall, this is the popular
__noSuchMethod__ case, so that one does not have to create a method
for each v
gt;From: William Edney [mailto:bed...@technicalpursuit.com]
>Sent: Wednesday, May 06, 2009 4:16 AM
>To: Brendan Eich
>Cc: Allen Wirfs-Brock; es-discuss Steen
>Subject: Re: Improving ECMAScript as a compilation target
>
>All -
>
>On May 6, 2009, at 1:15 AM, Brendan Eich wrote:
All -
On May 6, 2009, at 1:15 AM, Brendan Eich wrote:
But obj.prop() is worth a catchall, this is the popular
__noSuchMethod__ case, so that one does not have to create a method
for each value of 'prop' and retain it in obj under that name. The
call can be forwarded without any proxy or cl
On May 5, 2009, at 6:53 PM, Allen Wirfs-Brock wrote:
Still does not connote "non-existent".
If all these handlers are only invoked in missing property
situations then we can probably get away with an implicitly non-
existent connotation.
The ones that want to be called for existent proper
>-Original Message-
>From: Brendan Eich [mailto:bren...@mozilla.com]
...
>my "Art of the Meta-Object Protocol" is in a box somewhere for a
>reason ;-). But real-world use-cases are pressing upon us.
>
I dug mine out after the last F2F, it's been sitting on my desk unread since...
>
>> A si
p [1, 2, 3]
So perhaps invoke could be for non-callable (including non-existent,
i.e., imputed-undefined-value) properties.
/be
Allen
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Tuesday, May 05, 2009 11:32 AM
To: Allen Wirfs-Brock
Cc: es-discuss Steen
Subjec
ay 05, 2009 11:32 AM
>To: Allen Wirfs-Brock
>Cc: es-discuss Steen
>Subject: Re: Improving ECMAScript as a compilation target
>
>On May 5, 2009, at 12:26 AM, Brendan Eich wrote:
>
>> Still, as noted for delete above, full virtualization might want
>> every- and first- f
On May 5, 2009, at 12:26 AM, Brendan Eich wrote:
Still, as noted for delete above, full virtualization might want
every- and first- forms of all of the hooks. Instead of the add/set
split I wrote up, we could drop add and split all the hooks in two,
burdening the uncommon case with the long
On Mon, May 4, 2009 at 2:34 PM, Brendan Eich wrote:
> I finally found time to write up a proposal, sketchy and incomplete, but
> ready for some ever-lovin' es-discuss peer review ;-).
>
> http://wiki.ecmascript.org/doku.php?id=strawman:catchalls
>
> Comments welcome.
Thanks for posting your prop
On May 5, 2009, at 12:09 AM, Brendan Eich wrote:
"One user expectation, fed and watered by E4X, is that methods are
not properties, or to avoid this JS oxymoron, that methods are not
in the default property namespace:
js> x = 1216
12
16
js> x.length
16
js> x.length()
1
[snip]
The oth
On May 4, 2009, at 10:46 PM, Allen Wirfs-Brock wrote:
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
On May 4, 2009, at 6:20 PM, Allen Wirfs-Brock wrote:
In the function defined for the example's invoke item the first
argument to apply probably should be obj rather
>-Original Message-
>From: Brendan Eich [mailto:bren...@mozilla.com]
>
>On May 4, 2009, at 6:20 PM, Allen Wirfs-Brock wrote:
>
>> In the function defined for the example's invoke item the first
>> argument to apply probably should be obj rather than peer.
>
>Possibly, but in the example pee
Two open issues remain:
On May 4, 2009, at 6:20 PM, Allen Wirfs-Brock wrote:
In the function defined for the example's invoke item the first
argument to apply probably should be obj rather than peer.
Possibly, but in the example peer[id] may be a function that insists
on |this| being bound
Thanks, I incorporated the obvious fixes and left others as issues or
feedback items, and copied your sig once to credit your additions.
/be
On May 4, 2009, at 6:20 PM, Allen Wirfs-Brock wrote:
I also captured these on the wiki page:
In the function defined for the example's invoke item the
I also captured these on the wiki page:
In the function defined for the example's invoke item the first argument to
apply probably should be obj rather than peer.
I would be inclined to specify an additional argument (probably the first) for
each handler function that would be passed the "this"
On Feb 13, 2009, at 4:43 PM, Peter Michaux wrote:
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich
wrote:
We should talk about methodMissing for Harmony.
I did try
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008143.html
but nothing seems to have come of it yet
http://wi
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich wrote:
> We should talk about methodMissing for Harmony.
I did try
https://mail.mozilla.org/pipermail/es-discuss/2008-November/008143.html
but nothing seems to have come of it yet
http://wiki.ecmascript.org/doku.php?id=strawman:strawman
Pete
On Feb 13, 2009, at 11:42 AM, Allen Wirfs-Brock wrote:
Can you get off the fence on adding goto? How about call/cc?
For now, I only have problems, not solutions.
Me too :-).
However, I think it is debatable whether call/cc is more
approachable to beginners (who admittedly don't write com
>
>Can you get off the fence on adding goto? How about call/cc?
>
For now, I only have problems, not solutions. However, I think it is debatable
whether call/cc is more approachable to beginners (who admittedly don't write
compilers) than goto. Call/cc is probably less of an attractive nuisance
On Feb 13, 2009, at 11:23 AM, Brendan Eich wrote:
Tail calls is another feature I think benefit both especially as
interest in functional languages is rising
strongly.
I happen to agree, but these already foundered during ES4 development.
More recently, Waldemar objected to lambdas due to
On Feb 13, 2009, at 11:10 AM, Peter Michaux wrote:
On Fri, Feb 13, 2009 at 10:51 AM, Brendan Eich
wrote:
JS is used by many more programmers, amateur and pro, than C. It
has to have
better human factors than C. That goes against being a good code
generator
target language.
I think tha
On Feb 13, 2009, at 11:07 AM, Allen Wirfs-Brock wrote:
Brendan Eich wrote:
...
JS is used by many more programmers, amateur and pro, than C. It has
to have better human factors than C. That goes against being a good
code generator target language.
I totally agree with the first two sentenc
On Fri, Feb 13, 2009 at 10:51 AM, Brendan Eich wrote:
> JS is used by many more programmers, amateur and pro, than C. It has to have
> better human factors than C. That goes against being a good code generator
> target language.
I think that may not be true in all cases. methodMissing is an exam
>> Brendan Eich wrote:
...
>
>JS is used by many more programmers, amateur and pro, than C. It has
>to have better human factors than C. That goes against being a good
>code generator target language.
>
I totally agree with the first two sentences. I reserve judgment regarding the
third.
Allen
On Feb 13, 2009, at 7:45 AM, David-Sarah Hopwood wrote:
Brendan Eich wrote:
On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
If a "common language for hand-coders and code-generators" is
desirable, isn't it necessary to consider the code-generator part?
Yes.
I didn't agree that such a de
I haven't digested the details of this thread. However, I did want to go on
record as saying this is an area of interest to Microsoft and something we
would like to put more effort into (in the TC-39 context) after we wrap-up
ES3.1. Now back to trying to finish editing for the final draft ES3.
Brendan Eich wrote:
> On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
>
>> If a "common language for hand-coders and code-generators" is
>> desirable, isn't it necessary to consider the code-generator part?
Yes.
> I didn't agree that such a desert-topping/floor-wax was desirable.
Almost all p
On Feb 12, 2009, at 10:23 PM, Peter Michaux wrote:
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich
wrote:
On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
Not at all and it is unfortunate it came across that way. It is at
the
whole chain of events which is long: "for the ECMAScript committ
On Thu, Feb 12, 2009 at 10:16 PM, Brendan Eich wrote:
> On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
>
>> Not at all and it is unfortunate it came across that way. It is at the
>> whole chain of events which is long: "for the ECMAScript committee to
>> standardize methodMissing, for browsers
On Feb 12, 2009, at 9:41 PM, Peter Michaux wrote:
Not at all and it is unfortunate it came across that way. It is at the
whole chain of events which is long: "for the ECMAScript committee to
standardize methodMissing, for browsers to implement it and for old
browsers to disappear".
Standardizi
On Thu, Feb 12, 2009 at 9:17 PM, Brendan Eich wrote:
> On Feb 12, 2009, at 8:07 PM, Peter Michaux wrote:
>
> SpiderMonkey has had __noSuchMethod__ for years. The "Ten years" complaint
> you make seems to be against "the ECMAScript committee",
Not at all and it is unfortunate it came across that
On Feb 12, 2009, at 9:17 PM, Brendan Eich wrote:
The JVM bytecode is a counter-example and we are not going to
standardize anything like it in the near term (next few years).
I meant by "counter-example" an example of what not to do. Same goes
for SWF ABC (used by Flash), which Adobe does n
On Feb 12, 2009, at 8:07 PM, Peter Michaux wrote:
About five months ago I posted here about improving ECMAScript as a
compilation target.
https://mail.mozilla.org/pipermail/es-discuss/2008-September/007652.html
I was disappointed that there weren't any responses to that email.
Folks were proba
34 matches
Mail list logo
