Le 26/05/2011 22:19, David Flanagan a écrit :
On 5/26/11 10:46 AM, David Bruant wrote:
Le 26/05/2011 18:44, David Flanagan a écrit :
I'd put that distinction in an abstract Proxy.Handler class and then
rename the current Proxy.Handler to Proxy.ForwardingHandler.
What do you call a class is is
Le 27/05/2011 01:22, Waldemar a écrit :
Categorization:
No review, no advance:
Unicode
Concurrency
Enumeration
Simple module functions
No review, advance:
Multiple Globals
Maps and Sets
Math enhancements
Function.toString
Name property of functions
Review, advance:
String Extras
Array
On May 26, 2011, at 9:36 PM, Peter Michaux wrote:
I'm looking at the strawman for guards.
http://wiki.ecmascript.org/doku.php?id=strawman:guards
I don't quite see how they are created.
I understand this part about how they would be used
function f(p :: String, q :: MyType) ::
On May 27, 2011, at 1:39 AM, David Bruant wrote:
I do not see anything about proxies. If I remember well, a lot of decisions
had been delayed from the previous meeting to this one. Did something
happened about proxies?
Tom kindly agreed to move these issues to the July meeting, since
2011/5/26 David Bruant david.bru...@labri.fr
Le 26/05/2011 18:44, David Flanagan a écrit :
On 5/26/11 6:51 AM, Sean Eagan wrote:
Is think it would beneficial to replace all this.* calls in the
default trap implementations with Object.* methods and syntax that
subsequently triggers the
On May 26, 2011, at 4:22 PM, Waldemar wrote:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
The return will return out of f. Note also that the implementation of
forEach could have a try-finally statement that catches and revokes the
return. This kind of
Le 27/05/2011 04:13, Mark S. Miller a écrit :
On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu
mailto:cor...@cs.ucsc.edu wrote:
[documenting/expanding some ideas briefly discussed at today's
meeting]
The current proxy proposal has a method to create a new proxy:
On May 27, 2011, at 2:26 AM, David Bruant wrote:
Le 27/05/2011 04:13, Mark S. Miller a écrit :
On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu wrote:
[documenting/expanding some ideas briefly discussed at today's meeting]
The current proxy proposal has a method to
On 27/05/2011, at 11:01, Brendan Eich wrote:
On May 26, 2011, at 4:22 PM, Waldemar wrote:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
The return will return out of f. Note also that the implementation of
forEach could have a try-finally statement that catches and
Since I gather this proposal is meant primarily to support observable
objects, two remarks:
1) Are proxies the appropriate building block performance-wise? From the
notes, it seems that current proxies are not a good building block because
of performance issues. Are the performance issues related
I tend to agree with David about having a separate observable API, if that
is indeed the driving use case. That API can be very similar to the Proxy
API though. Racket's chaperones come to mind: a chaperone is a strictly
less powerful kind of proxy, one that is not allowed to arbitrarily
Le 27/05/2011 11:35, Brendan Eich a écrit :
On May 27, 2011, at 2:26 AM, David Bruant wrote:
Le 27/05/2011 04:13, Mark S. Miller a écrit :
On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu
mailto:cor...@cs.ucsc.edu wrote:
[documenting/expanding some ideas briefly
On 27/05/2011, at 11:36, Jorge wrote:
On 27/05/2011, at 11:01, Brendan Eich wrote:
On May 26, 2011, at 4:22 PM, Waldemar wrote:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
The return will return out of f. Note also that the implementation of
forEach could have a
On May 27, 2011, at 2:36 AM, Jorge wrote:
Also, I wonder if in order to make blocks first class, do we need any new
syntax ?
function f() {
a.forEach({ return 3 });
The problem is that a block statement is ambiguous with an object initialiser.
See
On Fri, May 27, 2011 at 5:45 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
I tend to agree with David about having a separate observable API, if that
is indeed the driving use case. That API can be very similar to the Proxy
API though. Racket's chaperones come to mind: a chaperone is a strictly
On 5/27/11 5:40 AM, Tom Van Cutsem wrote:
2) IIUC, one of the more interesting uses of observables would be to
make e.g. DOM nodes observable. That raises the issue of whether
Proxy.createFrom can be applied to Host objects, and of so, how to deal
with built-in [[...]] properties.
How useful
On May 27, 2011, at 3:04 AM, David Bruant wrote:
The idea of permitting this becomes operation only for extensible objects
with configurable properties is crucial.
Is it? The first time I heard about the become operation was in the context
of the proxy fix trap. Second time was this
I think the separation between proxies and regular objects is too
much. I would prefer to think of proxies as just a special kind of
object. All objects could be thought of as having a handler (
[[Handler]] ), and proxy objects could be those objects whose
handler is an actual ES object as
This may of been thrown though the ringer already but I thought I'd ask.
http://blog.stevenlevithan.com/archives/date-time-format
This is some awesome work on date formatting. What do we think about
having a native Date Format implementation in es.next? Complications?
Seems like this a very
On Fri, May 27, 2011 at 10:10 AM, Sean Eagan seaneag...@gmail.com wrote:
I think the separation between proxies and regular objects is too
much. I would prefer to think of proxies as just a special kind of
object. All objects could be thought of as having a handler (
[[Handler]] ), and proxy
On Fri, May 27, 2011 at 11:48 AM, Marc Harter wav...@gmail.com wrote:
This may of been thrown though the ringer already but I thought I'd ask.
http://blog.stevenlevithan.com/archives/date-time-format
This is some awesome work on date formatting. What do we think about
having a native Date
On May 27, 2011, at 8:10 AM, Sean Eagan wrote:
I think the separation between proxies and regular objects is too
much. I would prefer to think of proxies as just a special kind of
object. All objects could be thought of as having a handler (
[[Handler]] ), and proxy objects could be those
On Fri, May 27, 2011 at 11:08 AM, John Tamplin j...@google.com wrote:
On Fri, May 27, 2011 at 11:48 AM, Marc Harter wav...@gmail.com wrote:
This may of been thrown though the ringer already but I thought I'd ask.
http://blog.stevenlevithan.com/archives/date-time-format
This is some awesome
I have no intention of bike-shedding, but the following example keeps
popping up:
Arrow Function/Block:
function f() {
a.forEach({| | return 3});
}
...And I wonder if forEach was _only_ used to illustrate an example of the
block lambda syntax? If this was meant to serve as an actual
On Fri, May 27, 2011 at 12:21 PM, Marc Harter wav...@gmail.com wrote:
Note that it is rarely useful to format with a fixed pattern, because
different locales have different norms for ordering of the fields,
separators, etc.
By fixed pattern do you mean like d.format('YY/mm/dd')? If so,
This example was all about return in block-lambda returning from enclosing
function (the function f). That's all. Yeah, it was not useful code ;-).
/be
On May 27, 2011, at 9:42 AM, Rick Waldron wrote:
I have no intention of bike-shedding, but the following example keeps popping
up:
Thanks, I wasn't aware of that history.
I'm not suggesting that default handlers or traps even should exist
from an implementation perspective, just that they could be a nice
specification mechanism now that we have proxies. Otherwise we need
to separately maintain pseudocode and ES versions of
On Fri, May 27, 2011 at 12:18 PM, Sean Eagan seaneag...@gmail.com wrote:
Thanks, I wasn't aware of that history.
I'm not suggesting that default handlers or traps even should exist
from an implementation perspective, just that they could be a nice
specification mechanism now that we have
I'm puzzled about this idea. I thought that one of the main design
goals of proxies was that they are transparent, i.e. you cannot tell a
proxy apart from a proper object. How can this be maintained for
Proxy.createFrom? AFAICS, there is no way you can perform this
operation on an object that
On Fri, May 27, 2011 at 2:26 AM, David Bruant david.bru...@labri.fr wrote:
On Thu, May 26, 2011 at 5:04 PM, Cormac Flanagan cor...@cs.ucsc.edu wrote:
A design goal is that for any object that could be proxified,
we can replace it with a proxy in a way that is semantically transparent.
If you
On Fri, May 27, 2011 at 1:44 AM, Brendan Eich bren...@mozilla.com wrote:
On May 26, 2011, at 9:36 PM, Peter Michaux wrote:
I'm looking at the strawman for guards.
http://wiki.ecmascript.org/doku.php?id=strawman:guards
I don't quite see how they are created.
I understand this part
On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote:
Of course you could go the other way, and remove the default trap
implementations. All objects could have the same internal method
implementation regardless of whether or not they are a proxy. Within
each internal
On Fri, May 27, 2011 at 1:05 PM, Sean Eagan seaneag...@gmail.com wrote:
On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote:
Of course you could go the other way, and remove the default trap
implementations. All objects could have the same internal method
implementation
On 05/27/11 02:01, Brendan Eich wrote:
More was said here that is good feedback for Harmony, no matter what gets into
ES.next.
We talked about how shorter function syntax is hard to do well and standardize.
The traps include:
* do too little by ignoring 'return', jumping a syntax shark and
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux petermich...@gmail.com wrote:
A minifier could, couldn't it?
function foo(a::MyType) {}
would be minified to
function foo(a) {}
These are not the same function at all.
--
sam th
sa...@ccs.neu.edu
On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux petermich...@gmail.com wrote:
A minifier could, couldn't it?
function foo(a::MyType) {}
would be minified to
function foo(a) {}
These are not the same function
On Fri, May 27, 2011 at 1:05 PM, Sean Eagan seaneag...@gmail.com wrote:
On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote:
Of course you could go the other way, and remove the default trap
implementations. All objects could have the same internal method
implementation
On Fri, May 27, 2011 at 4:03 PM, Peter Michaux petermich...@gmail.com wrote:
On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux petermich...@gmail.com
wrote:
A minifier could, couldn't it?
function foo(a::MyType)
On Fri, May 27, 2011 at 1:24 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, May 27, 2011 at 4:03 PM, Peter Michaux petermich...@gmail.com wrote:
On Fri, May 27, 2011 at 12:55 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
On Fri, May 27, 2011 at 1:59 PM, Peter Michaux
I like the idea of putting .format() on the Date; it would allow for
quick and easy access to a handy formatter. However, would it make
more sense to use the set that php uses to format dates?[0] I would
assume that developers would be more familiar with that.
[0]:
On Fri, May 27, 2011 at 4:59 PM, Adam Shannon a...@ashannon.us wrote:
I like the idea of putting .format() on the Date; it would allow for
quick and easy access to a handy formatter. However, would it make
more sense to use the set that php uses to format dates?[0] I would
assume that
On Fri, May 27, 2011 at 4:43 PM, Peter Michaux petermich...@gmail.comwrote:
Yes but I was thinking of the use of guards as a debugging/development
tool. During development you can verify that foo is never called with
bad values. Then during production, those checks do not need to be
On May 27, 2011, at 12:27 PM, Waldemar Horwat wrote:
Peter Hallam kindly offered to help come up with a new grammar formalism for
the spec that can pass the Waldemar test (if that is possible; not as hard
as the Turing test). IIRC Peter said he was (had, would) adding arrow
support per the
On May 27, 2011, at 10:59 AM, Peter Michaux wrote:
I'm impressed with the following if this is what would actually be possible...
function(guard = identityGuard :: guardGuard)
What we have to write now in ES3 can be so long to achieve this kind
of default value and parameter checking
To a first, approximation, it would look something like this:
http://doc.racket-lang.org/reference/contracts.html
;-)
Seriously, the idea is to create contracts that can check structural properties
by wrapping values with proxies that lazily do the checking. The core idea,
known as
Sorry Mike, just saw your response. I think it would use the same
parsing technique as destructuring, the left hand side would need to
be post-processed. My grammar might need to be updated to make that
work though.
The pattern matching strawman [1] has a note about this:
Destructuring
On 05/27/11 16:00, Brendan Eich wrote:
On May 27, 2011, at 12:27 PM, Waldemar Horwat wrote:
Peter Hallam kindly offered to help come up with a new grammar formalism for the spec
that can pass the Waldemar test (if that is possible; not as hard as the
Turing test). IIRC Peter said he was
On Fri, May 27, 2011 at 9:20 PM, Waldemar Horwat walde...@google.com wrote:
Given that LR(1) is the most general grammar available before you start
getting into serious complexity (it subsumes LALR and other commonly studied
grammars),
This is simply begging the question on what is serious
On May 27, 2011, at 6:20 PM, Waldemar Horwat walde...@google.com wrote:
This produces expressions such as 42 = foo(), which must be handled by
semantic specification. Why can't we have a more precise grammar?
This is an entirely different issue. The LeftHandSideExpression is still
On May 27, 2011, at 6:42 PM, Brendan Eich wrote:
On May 27, 2011, at 6:20 PM, Waldemar Horwat walde...@google.com wrote:
This produces expressions such as 42 = foo(), which must be handled by
semantic specification. Why can't we have a more precise grammar?
This is an entirely different
50 matches
Mail list logo
