Re: prototype for operator proposal for review
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: prototype for operator proposal for review
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Unifying Binary Data and Typed Arrays
At the March meeting Binary Data was promoted to a Harmony proposal, and it was agreed that it would need to be further rationalized with existing Typed Arrays in browsers, including at least being interoperable with ArrayBuffer. With more reflection on this, I believe it is important that we embrace a single binary array model for JavaScript developers in the browser. To do this effectively while adding the struct and reference functionality of the Binary Data proposal, it would be useful to pull the existing Typed Arrays objects into ES.next, and add on top of them the necessary functionality to support Binary Data. We talked specifically about embracing ArrayBuffer and aligning the Binary Data Array objects with the ArrayBufferView interface. This allows for basic interop between the existing Web APIs and Binary Data objects. However, code is being written today using ArrayBuffer, Int32Array and related objects. Binary data allows constructing one's own Int32Array as new ArrayType(int32), but this will not replace the developer desire to use Int32Array directly. To unify the two array models, it would make sense to also embrace the specific array objects that are currently in browsers. I've updated the Binary Data Discussionhttp://wiki.ecmascript.org/doku.php?id=harmony:binary_data_discussion page with a note on the proposed extension which would incorporate the relevant objects into the proposal, and I've augmented the Typed Arrayshttp://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays page with a writeup of the relevant Typed Arrays objects in ECMAScript spec language separated from the WebIDL indirection. As part of the rationalization of Binary Data, I'd like to suggest that we embrace a single unified binary array story that embraces both the existing Typed Arrays functionality along with the block types, structs and references from Binary Data. Luke ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Private Names in 'text/javascript'
2011/5/18 Luke Hoban lu...@microsoft.com:
The Private Names strawman currently combines a new runtime capability
(using both strings and private names as keys in objects) with several new
syntactic constructs (private binding declarations, #.id). At the March
meeting, I recall there was some support for the idea of separating these
two aspects, and exposing the runtime capability also as a library that
could be used in ‘text/javascript’.
I'd like to support this idea.
Your example looks a bit wrong to me though. It seems to make new
private names per object. Surely we want a private name per 'class'
instead.
var Point = (function() {
var _x = Object.createPrivateName();
var _y = Object.createPrivateName();
var Point = function(x, y) {
this[_x] = x;
this[_y] = y;
}
Point.prototype.myMethodUsing_xAnd_y = function() {...}
return Point;
})()
var p = new Point(1, 2);
--
Erik Corry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Private Names in 'text/javascript'
Separating out the functionality of abstract names certainly is a good idea. But is there any reason to make it a method of Object? In essence, private names form a new primitive type, so there should be a separate global object or module for them. Assuming for a minute it was called Name (which clearly is a suboptimal choice), then you'd rather invoke Name.create(), or perhaps simply Name() (by analogy with calling String(v) to create primitive strings, although I'm not sure I like the notational abuse behind it). /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Private Names in 'text/javascript'
2011/5/18 Andreas Rossberg rossb...@google.com: Separating out the functionality of abstract names certainly is a good idea. But is there any reason to make it a method of Object? In essence, private names form a new primitive type, so there should be a separate global object or module for them. Assuming for a minute it was called Name (which clearly is a suboptimal choice), then you'd rather invoke Name.create(), or perhaps simply Name() (by analogy with calling String(v) to create primitive strings, although I'm not sure I like the notational abuse behind it). It would be nice to do Name(foo) or PrivateName(foo) so that the debugger has some name to use when displaying objects with private fields. Alternatively, I suppose the debugger could guess the name like it does currently for Foo.prototype.myFunc = function() This has the disadvantage that a library that uses unique strings to simulate some of the features of private names on older browsers would not be able to give the unique names a meaningful prefix. -- Erik Corry ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
On Wed, May 18, 2011 at 2:59 AM, Luke Hoban lu...@microsoft.com 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 sa...@ccs.neu.edu ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Harmony Proxies] Proposal: Property fixing
2011/5/12 David Bruant david.bru...@labri.fr
Le 12/05/2011 14:40, Tom Van Cutsem a écrit :
controversial invariant:
- proxies can't emulate non-configurable properties. If they would,
proxies could still update attributes of non-configurable properties.
Currently, proxies can emulate configurable properties (they are forced
to, but that's not my point). Still, a proxy can ignore
Object.defineProperty calls in the case of a re-configuration and also
ignore deletions, giving the impression that the property is
non-configurable even though Object.getOwnPropertyDescriptor would say
that configurable is set to true.
Proxies being able to lie about configurability is the exact mirror of
proxies being able to lie about non-configurability. However, one is
allowed, the other isn't.
Good point. However, Mark's distinction between eternal and momentary
invariants sheds some light on the differences. According to Mark's
classification, configurable:false comes with eternal guarantees, while
configurable:true does not. In other words: any assumptions that a program
makes that are based on the fact that a property is configurable are
necessarily momentary, since the property can become non-configurable
later. The reverse is not true.
I need to think more about the rest of your message.
Good work on the invariant enumeration. It may be incomplete as you
point out, but that's a good start anyway.
Among the enforced invariants, maybe that property names being strings
could be added if that is enforced. If it is, it requries to cast all
property names arguments to strings before trap calls. However,
enforcing this invariant may require to do the same on the array
returned by get{Own}PropertyNames/enumerate/keys. (maybe that it should
rather be in the controversial part :-) )
Proxies do coerce all property names to strings, e.g. proxy[obj] will
trigger the 'get' trap with 'obj' coerced to a String. This is not actually
enforced by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its
argument P is bound to a property name (a String)). At one point we
suggested removing this restriction, so that proxy[obj] would give the get
trap direct access to obj (which would be particularly useful when
intercepting numeric indices on array-like proxies). IIRC, we didn't pursue
this option since engines rely on property names being strings in other
places, and widening the type of property names to cover arbitrary objects
would be problematic.
Cheers,
Tom
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
On May 18, 2011, at 6:46 AM, Sam Tobin-Hochstadt wrote: On Wed, May 18, 2011 at 2:59 AM, Luke Hoban lu...@microsoft.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Harmony Proxies] Proposal: Property fixing
On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote: Proxies do coerce all property names to strings, e.g. proxy[obj] will trigger the 'get' trap with 'obj' coerced to a String. This is not actually enforced by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its argument P is bound to a property name (a String)). At one point we suggested removing this restriction, so that proxy[obj] would give the get trap direct access to obj (which would be particularly useful when intercepting numeric indices on array-like proxies). IIRC, we didn't pursue this option since engines rely on property names being strings in other places, and widening the type of property names to cover arbitrary objects would be problematic. SpiderMonkey has a wider internal property name type, which can accomodate at least int and object names. The int case is an optimization, commonly done. The object case is for E4X and perhaps private names. Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Harmony Proxies] Proposal: Property fixing
On Wed, May 18, 2011 at 7:38 AM, Brendan Eich bren...@mozilla.com wrote: On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote: Proxies do coerce all property names to strings, e.g. proxy[obj] will trigger the 'get' trap with 'obj' coerced to a String. This is not actually enforced by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its argument P is bound to a property name (a String)). At one point we suggested removing this restriction, so that proxy[obj] would give the get trap direct access to obj (which would be particularly useful when intercepting numeric indices on array-like proxies). IIRC, we didn't pursue this option since engines rely on property names being strings in other places, and widening the type of property names to cover arbitrary objects would be problematic. SpiderMonkey has a wider internal property name type, which can accomodate at least int and object names. The int case is an optimization, commonly done. The object case is for E4X and perhaps private names. Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC. That's the opposite of my memory, but it was a long time ago. Oliver? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Harmony Proxies] Proposal: Property fixing
On May 18, 2011, at 7:45 AM, Mark S. Miller wrote: On Wed, May 18, 2011 at 7:38 AM, Brendan Eich bren...@mozilla.com wrote: On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote: Proxies do coerce all property names to strings, e.g. proxy[obj] will trigger the 'get' trap with 'obj' coerced to a String. This is not actually enforced by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its argument P is bound to a property name (a String)). At one point we suggested removing this restriction, so that proxy[obj] would give the get trap direct access to obj (which would be particularly useful when intercepting numeric indices on array-like proxies). IIRC, we didn't pursue this option since engines rely on property names being strings in other places, and widening the type of property names to cover arbitrary objects would be problematic. SpiderMonkey has a wider internal property name type, which can accomodate at least int and object names. The int case is an optimization, commonly done. The object case is for E4X and perhaps private names. Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC. That's the opposite of my memory, but it was a long time ago. I was thinking of http://www.mail-archive.com/es-discuss@mozilla.org/msg05392.html at least. Probably some IRC convo after that as well, but at least that. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
paren-free call expressions
Hi,
Parens-free call expression allow to provide some actions
/decoratively/. From this, the consequence of easy and elegant DSLs
(domain specific languages). For example:
class Account {
attributes customer, cart
}
Thus, call to `attribute` function looks like not the imperative call,
but like a declaration that instances of Account class has those attributes.
Ruby uses exactly this approach of its attr_accessor, private, etc.
keywords which in fact are just functions placed on the very basic class:
class Foo
attr_accessor :x, :y
end
foo = Foo.new
foo.x = 10
foo.y = 20
which in fact is just a syntactic sugar (not at grammar, but at
application level via simple `attr_accessor` function) for the:
class Foo
def x
end
def x=(value)
end
def y
end
def y=(value)
end
end
That is, create getter and setter for every needed property (yes, in
Ruby all public properties are accessors). Thus, this function does it
behind the scene: attr_accessor(:x, :y), however being called /without/
parens, it elegantly looks like a declarative keyword. Another example
as is said, `private` function which also without parens looks like an
operator.
Besides, If - will be accepted, in many cases (being passed as
callback) they will much more elegantly look without parens of call
expressions.
So what do you think? If the idea is good, may it bring some problems
with parsers and grammar?
P.S.: some examples of declarative DSLs:
https://github.com/jashkenas/coffee-script/wiki/%5BExtensibility%5D-Writing-DSLs
Dmitry.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: [Harmony Proxies] Proposal: Property fixing
On Wed, May 18, 2011 at 8:50 AM, Brendan Eich bren...@mozilla.com wrote: On May 18, 2011, at 7:45 AM, Mark S. Miller wrote: [...] Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC. That's the opposite of my memory, but it was a long time ago. I was thinking of http://www.mail-archive.com/es-discuss@mozilla.org/msg05392.html at least. Probably some IRC convo after that as well, but at least that. I stand corrected. Thanks for the clarification. -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: [Harmony Proxies] Proposal: Property fixing
IIRC I was saying that the engine should simply allow non-objects types to pass through uncoerced, rather than taking any particular stance on ease of implementation. I suspect in JSC that we would be able to do it without too much difficulty, but there's a a world of difference between that, and it actually being the case. --Oliver On May 18, 2011, at 7:45 AM, Mark S. Miller wrote: On Wed, May 18, 2011 at 7:38 AM, Brendan Eich bren...@mozilla.com wrote: On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote: Proxies do coerce all property names to strings, e.g. proxy[obj] will trigger the 'get' trap with 'obj' coerced to a String. This is not actually enforced by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its argument P is bound to a property name (a String)). At one point we suggested removing this restriction, so that proxy[obj] would give the get trap direct access to obj (which would be particularly useful when intercepting numeric indices on array-like proxies). IIRC, we didn't pursue this option since engines rely on property names being strings in other places, and widening the type of property names to cover arbitrary objects would be problematic. SpiderMonkey has a wider internal property name type, which can accomodate at least int and object names. The int case is an optimization, commonly done. The object case is for E4X and perhaps private names. Oliver wrote in the thread at the time that he thought allowing any value to be used as a property name (in brackets) and passed through uncoerced to proxies was implementable without trouble for JavaScriptCore, IIRC. That's the opposite of my memory, but it was a long time ago. Oliver? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: paren-free call expressions
I'm working on a block-as-better-function proposal, essentially an alternative
to arrow-function-syntax even though unlike the latter, the former has new
semantics.
One of the insights from Allen and Mark, which is kind of obvious to Rubyists,
is that blocks as lightweight functions usable for building control
abstractions really need paren-free calls to be as light as in Smalltalk,
therefore actually usable compared to writing loops or even old-fashioned
function expressions.
Sure, block-lambdas are good as lighter functions too, but they're not enough,
and the TCP wins were considered losses in that context. This is because a
function can escape from a downward flow and later be invoked, then attempt to
return from the activation of its static parent function after that function's
activation has been deallocated.
A block may not escape. Indeed Ruby's simplest downward-funarg block protocol
involves caller passing a block via a paren-free call, and the receiving
method not declaring the formal, rather just calling it via Ruby's yield. No
escape.
Anyway, I'm going to include paren-free call syntax in the block-lambda
proposal, not factor it out. It probably could be, but it's not as simple as
you show. In particular,
foo = Foo.new
in Harmony should continue to get the 'new' property from Foo and assign it to
foo. It should not implicitly call Foo.new().
/be
On May 18, 2011, at 8:53 AM, Dmitry A. Soshnikov wrote:
Hi,
Parens-free call expression allow to provide some actions decoratively. From
this, the consequence of easy and elegant DSLs (domain specific languages).
For example:
class Account {
attributes customer, cart
}
Thus, call to `attribute` function looks like not the imperative call, but
like a declaration that instances of Account class has those attributes.
Ruby uses exactly this approach of its attr_accessor, private, etc.
keywords which in fact are just functions placed on the very basic class:
class Foo
attr_accessor :x, :y
end
foo = Foo.new
foo.x = 10
foo.y = 20
which in fact is just a syntactic sugar (not at grammar, but at application
level via simple `attr_accessor` function) for the:
class Foo
def x
end
def x=(value)
end
def y
end
def y=(value)
end
end
That is, create getter and setter for every needed property (yes, in Ruby all
public properties are accessors). Thus, this function does it behind the
scene: attr_accessor(:x, :y), however being called without parens, it
elegantly looks like a declarative keyword. Another example as is said,
`private` function which also without parens looks like an operator.
Besides, If - will be accepted, in many cases (being passed as callback)
they will much more elegantly look without parens of call expressions.
So what do you think? If the idea is good, may it bring some problems with
parsers and grammar?
P.S.: some examples of declarative DSLs:
https://github.com/jashkenas/coffee-script/wiki/%5BExtensibility%5D-Writing-DSLs
Dmitry.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
On Wed, May 18, 2011 at 11:53 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Private Names in 'text/javascript'
On May 18, 2011, at 4:42 AM, Erik Corry wrote: 2011/5/18 Andreas Rossberg rossb...@google.com: Separating out the functionality of abstract names certainly is a good idea. But is there any reason to make it a method of Object? In essence, private names form a new primitive type, so there should be a separate global object or module for them. Assuming for a minute it was called Name (which clearly is a suboptimal choice), then you'd rather invoke Name.create(), or perhaps simply Name() (by analogy with calling String(v) to create primitive strings, although I'm not sure I like the notational abuse behind it). It would be nice to do Name(foo) or PrivateName(foo) so that the debugger has some name to use when displaying objects with private fields. Alternatively, I suppose the debugger could guess the name like it does currently for Foo.prototype.myFunc = function() This has the disadvantage that a library that uses unique strings to simulate some of the features of private names on older browsers would not be able to give the unique names a meaningful prefix. As Dave mentioned earlier in this thread he and I are still working on a unified proposal. Luke mentioned my latest working draft that tries to address some of the issue mentioned above. It is at http://wiki.ecmascript.org/doku.php?id=strawman:unique_string_values. Note however, that this iteration is not necessarily what we will end up proposing. In general, it is a good idea to avoid new global names that aren't going to be in modules. In particular, there is no particular reason these factory methods shouldn't be visible via the Harmony ES5 global object. In that case hanging them off an existing constructor carries less risk of collisions (but not no risk) with user defined name. Name seems like it might be a particularly risky global to grab. Luke suggested hanging them off Object and in my working draft I suggest String. Either is probably safer than adding new globals. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Use cases for WeakMap
Off topic. Hi Rick, my name is Rick. Nice to meet you. - Rick On Tue, May 17, 2011 at 10:06 AM, Hudson, Rick rick.hud...@intel.comwrote: This is all a bit off topic but performance does matter and folks seem to be underestimating the wealth of community knowledge that exists in this area. Who underestimates? Sorry, this wasn’t meant to slight anyone. I have spent a career standing on the shoulders of Allen and his colleagues. My respect should not be underestimated. Interesting pointer. -Rick *From:* Brendan Eich [mailto:bren...@mozilla.com] *Sent:* Monday, May 16, 2011 6:44 PM *To:* Hudson, Rick *Cc:* Allen Wirfs-Brock; Oliver Hunt; Andreas Gal; es-discuss *Subject:* Re: Use cases for WeakMap On May 16, 2011, at 2:46 PM, Hudson, Rick wrote: This is all a bit off topic but performance does matter and folks seem to be underestimating the wealth of community knowledge that exists in this area. Who underestimates? A bunch of us are aware of all this. Allen certainly knows all about it, and we've been talking shop with him for years, long before he joined Mozilla :-P. I recall a conversation like this one about sparse hashcode implementation with Allen, Lars Thomas Hansen (then of Opera), and Graydon Hoare from four or five years ago... http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes (check the history) However, in this thread, the issue is *not* optimizing hashcode or other metadata sparsely associated with objects. That's a good thing, implementations should do it. Having the hashcode in the object wins, compared to having it (initially) in a side table, but who's counting? The issue under dispute was neither sparse hashcode nor sparse fish property association, where the property would be accessed by JS user code that referenced the containing object itself. Rather, it was whether a frozen object needed *any* hidden mutable state to be a key in a WeakMap. And since this state would be manipulated by the GC, it matters if it's in the object, since the GC would be touching more potentially randomly distributed memory, thrashing more cache. So far as I can tell, there's no demonstrated need for this hidden-mutable key-in-weakmap object state. And it does seem that touching key objects unnecessarily will hurt weakmap-aware GC performance. But I may be underestimating... :-/ /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 mean the object on the right points at the object on the left (via [[Prototype]])? That, I buy. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
On Wed, May 18, 2011 at 10:10 AM, Brendan Eich bren...@mozilla.com 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 should be independent of any prior exposure to UML. Do you mean the object on the right points at the object on the left (via [[Prototype]])? That, I buy. JEEZ! Yes, that's what I meant. Thanks for the quick correction. /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 ho! Maybe enterprise Java heads... 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 will see a resurgence of UML for documenting JS designs in which case people may curse us if we choose today to make the triangle point the wrong direction ;-) Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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, 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 | could work but I think we agree that the object literal (or array or function for that matter) really needs to be on the right for readability. In that case | seems to be point ingin the wrong direction from any of the perspectives: UML generalization, [[Prototype]] pointer direction, type specialization... Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 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 | could work but I think we agree that the object literal (or array or function for that matter) really needs to be on the right for readability. In that case | seems to be point ingin the wrong direction from any of the perspectives: UML generalization, [[Prototype]] pointer direction, type specialization... Gotcha, I'm sold. It's an idiom. I will go play TMBG Particle Man, the Triangle Man verse. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
On Mon, May 16, 2011 at 8:02 AM, Brendan Eich bren...@mozilla.com wrote:
On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote:
Regarding `new` keyword for the constructor (aka initializer), after all,
it als may be OK. E.g. Ruby uses `new` as exactly the method of a class --
Array.new, Object.new, etc. Though, `constructor` is also good yeah.
My point is not to bikeshed, rather (a) to name existing prototype
properties minimally, (b) to avoid preempting other names.
Using new for the constructor is one of my favorite feature's of Allen's
proposal. Things I like about it:
1. It's terse. Since almost every class defines a ctor, this is helpful.
constructor is a mouthful and repeating the full class name (like in Java,
C++, etc.) is redundant.
2. I think it's pretty clear to a user what's going on.
3. It avoids stealing a valid identifier. You can't define a method named
new but constructor is a valid property name.
Good, bad, or in between, the prototypal pattern in JS for constructor C
binds C.prototype.constructorr to C. It does not bind C.prototype.new.
That's true, but I hope for classes is to hide just that machinery. There's
no mention of prototype when you define a property on that object inside a
class but that's what happens under the hood.
My hope is that users should almost never need to know or care that
C.prototype.constructor is bound to C. Instead, what I'd like is for class
to be a valid expression inside a class member that evaluates to C. Instead
of:
class math.geometry.Circle {
class var pi = 3;
new(radius) {
this.radius = radius;
}
get circumference() {
return this.radius * 2 * math.geometry.Circle.pi;
}
}
Be able to do:
class math.geometry.Circle {
class var pi = 3;
new(radius) {
this.radius = radius;
}
get circumference() {
return this.radius * 2 * class.pi; // ---
}
}
- bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: prototype for operator proposal for review
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 will see a resurgence of UML for documenting JS designs in which case people may curse us if we choose today to make the triangle point the wrong direction ;-) You can't be too sure. They might have lots of other reason to curse. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
On Tue, May 17, 2011 at 11:09 AM, Shawn Steele shawn.ste...@microsoft.comwrote: I would much prefer changing UCS-2 to UTF-16, thus formalizing that surrogate pairs are permitted. That'd be very difficult to break any existing code and would still allow representation of everything reasonable in Unicode. That would enable Unicode, and allow extending string literals and regular expressions for convenience with the U+10 style notation (which would be equivalent to the surrogate pair). The character code manipulation functions could be similarly augmented without breaking anything (and maybe not needing different names?) You might want to qualify the UTF-16 as allowing, but strongly discouraging, lone surrogates for those people who didn't realize their binary data wasn't a string. The sole disadvantage would be that iterating through a string would require consideration of surrogates, same as today. The same caution is also necessary to avoid splitting Ä (U+0041 U+0308) into its component A and ̈ parts. I wouldn't be opposed to some sort of helper functions or classes that aided in walking strings, preferably with options to walk the graphemes (or whatever), not just the surrogate pairs. FWIW: we have such a helper for surrogates in .Net and nobody uses them. The most common feedback is that it's not that helpful because it doesn't deal with the graphemes. Hmm... I proposed break iterators for 'character/grapheme', word, line and sentence as a part of i18n API, but it's shot down (at least for version 0.5). Are you open to adding them now ? Once this discussion is settled and the proposal to support the full unicode range is in place, we can revisit the issue. Jungshik - Shawn shawn.ste...@microsoft.com Senior Software Design Engineer Microsoft Windows ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
On Tue, May 17, 2011 at 20:01, Wes Garland w...@page.ca wrote:
Mark;
Are you Dr. *Mark E. Davis* (born September 13, 1952 (age 58)), co-founder
of the Unicode http://en.wikipedia.org/wiki/Unicode project and the
president of the Unicode
Consortiumhttp://en.wikipedia.org/wiki/Unicode_Consortiumsince its
incorporation in 1991?
Guilty as charged.
(If so, uh, thanks for giving me alternatives to Shift-JIS, GB-2312, Big-5,
et al..those gave me lots of hair loss in the late 90s)
Your welcome. We did it to save ourselves from the hair-pulling we had in
the *80's* over those charsets ;-)
On 17 May 2011 21:55, Mark Davis ☕ m...@macchiato.com wrote:In the past,
I have read it thus, pseudo BNF:
UnicodeString = CodeUnitSequence // D80
CodeUnitSequence = CodeUnit | CodeUnitSequence CodeUnit // D78
CodeUnit = anything in the current encoding form // D77
So far, so good. In particular, d800 is a code unit for UTF-16, since it
is a code unit that can occur in some code unit sequence in UTF-16.
*head smack* - code unit, not code point.
This means that your original assertion -- that Unicode strings cannot
contain the high surrogate code points, regardless of meaning -- is in fact
correct.
That is incorrect.
Aie, Karumba!
If we have
- a sequence of code points
- taking on values between 0 and 0x1F
10
- including high surrogates and other reserved values
- independent of encoding
..what exactly are we talking about? Can it be represented in UTF-16
without round-trip loss when normalization is not performed, for the code
points 0 through 0x?
Surrogate code points (U+D800..U+DFFF) can't be represented in any
*UTF*string. They can, be represented in
*Unicode strings* (ones that are not valid UTF strings) with the one
restriction that in UTF-16, they have to be isolated. In practice, we just
don't find that isolated surrogates in Unicode 16-bit strings cause a
problem, so I think that issue has derailed the more important issues
involved in this discu, which are in the API.
Incidentally, I think this discussion underscores nicely why I think we
should work hard to figure out a way to hide UTF-16 encoding details from
user-end programmers.
The biggest issue is the indexing. In Java, for example, iterating through a
string is has some ugly syntax:
int cp;
for (int i = 0; i string.length(); i += *Character.charCount*(cp)) {
cp = string.*codePointAt*(i);
doSomethingWith(cp);
}
But it doesn't have to be that way; they could have supported, with a little
bit of semantic sugar, something like:
for (int cp : aString) {
doSomethingWith(cp);
}
If done well, the complexity doesn't have to show to the user. In many
cases, as Shawn pointed out, codepoints are not really the right unit
anyway. What the user may actually need are word boundaries, or grapheme
cluster boundaries, etc. If, for example, you truncate a string on just code
point boundaries, you'll get the wrong answer sometimes.
It is of course simpler, if you are either designing a programming language
from scratch *or* are able to take the compatibility hit, to have the API
for strings always index by code points. That is, from the outside, a string
always looks like it is a simple sequence of code points. There are a couple
of ways to do that efficiently, even where the internal storage is not 32
bit chunks.
Wes
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: prototype for operator proposal for review
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. 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. While this may be true, why does it matter? JS is imperative and dynamic. So refactoring tools, etc. have to learn how to deal with it, easy or not easy. jjb Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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]/ | newRegExpMethods
var o = {
a:0,
b: function () {}
} | myProto
The mnemonic is preserved, but I find this a little more natural to read. In
particular:
1. The data specific to this instance appears first.
2. The | can be read as extends instead of is extended by.
3. The objects are ordered from left-to-right in the order that properties
on them are looked up. Given foo | bar we'll look for a property on foo
then bar.
Personally, I don't have a strong opinion since I don't think I'd use this
much regardless of syntax, but I wanted to put this out there.
- bob
On Wed, May 18, 2011 at 10:34 AM, Brendan Eich bren...@mozilla.com wrote:
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 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
| could work but I think we agree that the object literal (or array or
function for that matter) really needs to be on the right for readability.
In that case | seems to be point ingin the wrong direction from any of the
perspectives: UML generalization, [[Prototype]] pointer direction, type
specialization...
Gotcha, I'm sold. It's an idiom.
I will go play TMBG Particle Man, the Triangle Man verse.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
Using new for the constructor is one of my favorite feature's of Allen's
proposal. Things I like about it:
1. It's terse. Since almost every class defines a ctor, this is helpful.
constructor is a mouthful and repeating the full class name (like in Java,
C++, etc.) is redundant.
2. I think it's pretty clear to a user what's going on.
3. It avoids stealing a valid identifier. You can't define a method named
new but constructor is a valid property name.
Yes you can:
var obj = {
new: function() { print(hey what's up) }
}
To my mind, this slightly weakens the case for |new| over |constructor|. You'd
be special-casing the syntax *not* to create a property called new even
though in object literals it does.
But I'm somewhat divided about this particular issue. You're right that the
longer name hurts both for writing and reading. In both cases, the name is
being special-cased (in either case, there's something special going on: the
function defines the call and construct behavior of the class's constructor
function, and both the instance *and* the prototype are given a property called
|constructor|). But arguably there's something slightly less surprising about
giving the special-case semantics to a reserved word, and of course only in the
context of a class body. And yet, as I said above, there is something slightly
weird about *not* creating a property called new when using the keyword
|new|. (I think it would be a bad idea to have it create *both* a property
called |constructor| *and* a property called |new|.)
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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:proto_operator Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
On May 18, 2011, at 10:58 AM, Bob Nystrom wrote: On Mon, May 16, 2011 at 8:02 AM, Brendan Eich bren...@mozilla.com wrote: On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote: Regarding `new` keyword for the constructor (aka initializer), after all, it als may be OK. E.g. Ruby uses `new` as exactly the method of a class -- Array.new, Object.new, etc. Though, `constructor` is also good yeah. My point is not to bikeshed, rather (a) to name existing prototype properties minimally, (b) to avoid preempting other names. Using new for the constructor is one of my favorite feature's of Allen's proposal. Things I like about it: 1. It's terse. Since almost every class defines a ctor, this is helpful. constructor is a mouthful and repeating the full class name (like in Java, C++, etc.) is redundant. The whole of class declaration is a mouthful. 'function' and 'prototype' are overlong too. We can try for conciseness in this one corner but it doesn't help in general. I think we need to weight the whole syntax and see where the verbosity *and other* pain points are in practice. 2. I think it's pretty clear to a user what's going on. Same with 'constructor', and that property must exist somehow. Why not be explicit and avoid having two names for one prototype property? 3. It avoids stealing a valid identifier. You can't define a method named new but constructor is a valid property name. 3 is false in ES5. Reserved identifiers are valid property names. This is implemented in all the ES5-supporting browsers. /be___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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.) /be On May 18, 2011, at 11:44 AM, Allen Wirfs-Brock wrote: 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:proto_operator Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
On Wed, May 18, 2011 at 11:48 AM, Brendan Eich bren...@mozilla.com wrote:
The whole of class declaration is a mouthful. 'function' and 'prototype'
are overlong too.
Agreed. One of the reasons I'm really excited about this proposal is that it
addresses those:
// old and busted
function SomeClass() {}; SomeClass.prototype.someMethod = function(arg) {
... }
// new hotness
class SomeClass { someMethod(arg) { ... } }
We can try for conciseness in this one corner but it doesn't help in
general. I think we need to weight the whole syntax and see where the
verbosity *and other* pain points are in practice.
Sure. I'm not stuck on new, but in the chunks of sample code I've put
together using constructor (which is what Traceur uses/did use for a good
while) it did actually stick out as a syntactic wart, at least to me.
Same with 'constructor', and that property must exist somehow. Why not be
explicit and avoid having two names for one prototype property?
3 is false in ES5. Reserved identifiers are valid property names. This is
implemented in all the ES5-supporting browsers.
Ah, my mistake. These are both fair points. It's too bad constructor is
such a long word.
In the interests of considering all possibilities, one option would be to
use no name at all for the constructor:
class Point {
(x, y) {
this.x = x;
this.y = y;
}
}
I find that simultaneously delightfully lightweight and terrifyingly
obscure.
- bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: paren-free call expressions
On 18.05.2011 20:16, Brendan Eich wrote:
I'm working on a block-as-better-function proposal, essentially an
alternative to arrow-function-syntax even though unlike the latter,
the former has new semantics.
One of the insights from Allen and Mark, which is kind of obvious to
Rubyists, is that blocks as lightweight functions usable for building
control abstractions really need paren-free calls to be as light as in
Smalltalk, therefore actually usable compared to writing loops or even
old-fashioned function expressions.
Yeah, right.
Sure, block-lambdas are good as lighter functions too, but they're not
enough, and the TCP wins were considered losses in that context.
Sorry, TCP? What's that?
This is because a function can escape from a downward flow and later
be invoked, then attempt to return from the activation of its static
parent function after that function's activation has been deallocated.
Yeah, a casual bidirectional (up/down) closure.
A block may not escape. Indeed Ruby's simplest downward-funarg block
protocol involves caller passing a block via a paren-free call, and
the receiving method not declaring the formal, rather just calling it
via Ruby's yield. No escape.
Just only if the receiving method doesn't define the block explicitly
via the last -argument. It's exactly the explicit block which is
transformed to the Proc-object, and already this object can be returned
upward. Though, there's no much sense in it, since the block is created
lexically in the caller context and all caller's bindings are already
closured in it anyway (will it be returned back or not -- no matter).
Anyway, I'm going to include paren-free call syntax in the
block-lambda proposal, not factor it out. It probably could be, but
it's not as simple as you show. In particular,
foo = Foo.new
in Harmony should continue to get the 'new' property from Foo and
assign it to foo. It should not implicitly call Foo.new().
Oh, of course. The same as in CoffeeScript. It will be a simple property
reading, not calling. In Coffee we have to used () for calling a
function without parameters. However in Ruby as is said there are no
simple properties, all public stuff are _only_ methods. `foo.bar` -- is
calling a method. `foo.bar = 10` -- is calling the method `bar=`, it's
actually exactly parens-free mode of foo.bar=(10).
So in JS/Coffee I do not expect Foo.new behave as a method. But Foo.new
{x: 10} -- yes, and it's very convenient for declarative DSL.
P.S.: so in proposal it will look like:
[1, 2, 3].map {|x| x * x}
not like this:
[1, 2, 3].map({|x| x * x});
right? (just asking to include to the following talk)
Dmitry.
On May 18, 2011, at 8:53 AM, Dmitry A. Soshnikov wrote:
Hi,
Parens-free call expression allow to provide some actions
/decoratively/. From this, the consequence of easy and elegant DSLs
(domain specific languages). For example:
class Account {
attributes customer, cart
}
Thus, call to `attribute` function looks like not the imperative
call, but like a declaration that instances of Account class has
those attributes.
Ruby uses exactly this approach of its attr_accessor, private, etc.
keywords which in fact are just functions placed on the very basic
class:
class Foo
attr_accessor :x, :y
end
foo = Foo.new
foo.x = 10
foo.y = 20
which in fact is just a syntactic sugar (not at grammar, but at
application level via simple `attr_accessor` function) for the:
class Foo
def x
end
def x=(value)
end
def y
end
def y=(value)
end
end
That is, create getter and setter for every needed property (yes, in
Ruby all public properties are accessors). Thus, this function does
it behind the scene: attr_accessor(:x, :y), however being called
/without/ parens, it elegantly looks like a declarative keyword.
Another example as is said, `private` function which also without
parens looks like an operator.
Besides, If - will be accepted, in many cases (being passed as
callback) they will much more elegantly look without parens of call
expressions.
So what do you think? If the idea is good, may it bring some problems
with parsers and grammar?
P.S.: some examples of declarative DSLs:
https://github.com/jashkenas/coffee-script/wiki/%5BExtensibility%5D-Writing-DSLs
Dmitry.
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
i18n meeting venue/agenda
Hi everybody, our May meeting is next week, 10-17h, May 23. 2011. You are welcome to show in person at Googlehttp://maps.google.com/maps?hl=enq=900+alta+ave+mountain+viewie=UTF8hq=hnear=900+Alta+Ave,+Mountain+View,+California+94043gl=ussqi=2z=16campus. Please ask the receptionist at 900 Alta Ave. about EcmaScript meeting and she'll call me to pick you up. For teleconference please dial: International direct: +1 617 224.4646 US Toll free: 1 866 457.4646 Participant passcode: 15242605 then # Agenda (please respond with suggestions): - Final pass over API - Resolve problems that surfaced during implementation (we have Amazon implementation, and Google v8 for now) - Next steps wrt. writing formal document -- Nebojša Ćirić ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ECMAScripts tests regarding SES
Hi, This message regards Secure ECMAScript (SES) [1] (by the way, can links like [2], [3] or [4] be added to the ses wiki page?). SES requires initSES.js to run. An environment where this happens is called Secureable EcmaScript 5 (please correct if I misunderstand or misuse the terminology). Regarding Securable ECMAScript 5, are there particular aspects of ES5 that would need to be tested in order to make sure not only that initSES.js runs but also does what is expected from it. In other words, are there tests that could be added to Test262 in order to help ensuring an ES5 implementation is securable with very high confidence? Or is the current test suite sufficient? David [1] http://wiki.ecmascript.org/doku.php?id=ses:ses [2] http://code.google.com/p/es-lab/wiki/SecureEcmaScript [3] http://code.google.com/p/es-lab/wiki/SecureableES5 [4] http://code.google.com/p/es-lab/source/browse/trunk/src/ses/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
i18n API implementation issues
Hi all,
Jungshik and I were working on v8 implementation and we have almost
everything done (number formatting is not done, and some parts of
collation). There are some issues I would like to discuss (I made an update
to the strawman):
1. For LocaleInfo I would like to include construction with plain string:
new LocaleInfo(*de*) vs more verbose new LocaleInfo(*{'languageID': 'de'}*
)
One would be able to construct LocaleInfo like this:
LocaleInfo(); - default
LocaleInfo('sr');
LocaleInfo({}); - default
LocaleInfo({'languageID': 'sr', 'regionID': 'RU'); - and all variations
(missing regionID, missing languageID).
2. Language matching - how detailed should we go in specifying language
matching process?
I assume each platform has its own way of finding the best match for a user
provided language ID. Should we just leave it at that?
I would like to propose one requirement:
If user specifies de-AT-u-co-phonebk and language matcher produces de-DE
as closest match, we should keep the extension and produce final
de-DE-u-co-phonebk.
3. Derive methods were introduced to simplify creation of objects by
tweaking current settings. It works well when you override existing setting
or when you add new one. It's not so great when you want to remove a
setting. For example:
var dtf = new DateTimeFormat({'skeleton': 'MMMy'});
// Skeleton has higher priority than timeType and dateType fields so we have
to remove it in order for dateType override to have any effect.
var derivedDtf = dtf.*derive*({'skeleton': undefined, 'dateType': 'short');
The example is somewhat forced since user would probably just create new DTF
in this case instead of deriving, but I wanted to show the problem with
reseting the setting.
The question is - do we keep derive methods? If so, do we care about this
case/my solution (since user has other ways to create the object)?
4. Should we rename LocaleInfo.*collator*()/*numberFormat*()/*dateTimeFormat
*() into LocaleInfo.*createCollator*()...? It makes it clear we are creating
new object.
5. I think that *calendar* settings for DateTimeFormat doesn't bring much
value and makes implementation more complex. Overriding default calendar is
rare operation, and can be easily done with -u-ca extension - one just needs
to create new locale.
6. I would rename *dateSkeleton* into *skeleton* in DateTimeFormat settings.
--
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Full Unicode strings strawman
Hmm... I proposed break iterators for 'character/grapheme', word, line and sentence as a part of i18n API, but it's shot down (at least for version 0.5). Are you open to adding them now ? Once this discussion is settled and the proposal to support the full unicode range is in place, we can revisit the issue. That’s still a hard problem, particularly for i18n v0.5. However that’s probably a “better” problem to solve than “how to count supplementary characters”. -Shawn ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
Yes, one of the options for the internal storage of the string class is to use different arrays depending on the contents. 1. uint8's if all the codepoint are =FF 2. uint16's if all the codepoint values = 3. uint32's otherwise That way the internal storage always corresponds directly to the code point index, which makes random access fast. Case #3 occurs rarely, so it is ok if it takes more storage in that case. Mark *— Il meglio è l’inimico del bene —* On Wed, May 18, 2011 at 14:46, Erik Corry erik.co...@gmail.com wrote: 2011/5/17 Wes Garland w...@page.ca: If you're already storing UTF-8 strings internally, then you are already doing something expensive (like copying) to get their code units into and out of JS; so no incremental perf impact by not having a common UTF-16 backing store. (As a note, Gecko and WebKit both use UTF-16 internally; I would be _really_ surprised if Trident does not. No idea about Presto.) FWIW - last I time I scanned the v8 sources, it appeared to use a three-representation class, which could store either ASCII, UCS2, or UTF-8. Presumably ASCII could also be ISO-Latin-1, as both are exact, naive, byte-sized UCS2/UTF-16 subsets. V8 has ASCII strings and UCS2 strings. There are no Latin1 strings and UTF-8 is only used for IO, never for internal representation. WebKit uses UCS2 throughout and V8 is able to work directly on WebKit UCS2 strings that are on WebKit's C++ heap. I like Shawn Steele's suggestion. -- Erik Corry ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
On May 18, 2011, at 2:04 PM, Nebojša Ćirić wrote:
Hi all,
Jungshik and I were working on v8 implementation and we have almost
everything done (number formatting is not done, and some parts of collation).
There are some issues I would like to discuss (I made an update to the
strawman):
1. For LocaleInfo I would like to include construction with plain string:
new LocaleInfo(de) vs more verbose new LocaleInfo({'languageID': 'de'})
One would be able to construct LocaleInfo like this:
LocaleInfo(); - default
LocaleInfo('sr');
LocaleInfo({}); - default
LocaleInfo({'languageID': 'sr', 'regionID': 'RU'); - and all variations
(missing regionID, missing languageID).
you don't need quotes around the property names in your literal objects:
LocaleInfo({languageID: 'sr', regionID: 'RU');
You could support all of the above, it's just a matter of some internal logic.
You really have tree alternative for the argument:
none,
a string
an object that will be treated as a possibly empty set of option properties
2. Language matching - how detailed should we go in specifying language
matching process?
I assume each platform has its own way of finding the best match for a user
provided language ID. Should we just leave it at that?
I would like to propose one requirement:
If user specifies de-AT-u-co-phonebk and language matcher produces de-DE
as closest match, we should keep the extension and produce final
de-DE-u-co-phonebk.
Precise specification is best for interoperability. Specify as much as you
possibly can.
3. Derive methods were introduced to simplify creation of objects by tweaking
current settings. It works well when you override existing setting or when
you add new one. It's not so great when you want to remove a setting. For
example:
var dtf = new DateTimeFormat({'skeleton': 'MMMy'});
// Skeleton has higher priority than timeType and dateType fields so we have
to remove it in order for dateType override to have any effect.
var derivedDtf = dtf.derive({'skeleton': undefined, 'dateType': 'short');
The example is somewhat forced since user would probably just create new DTF
in this case instead of deriving, but I wanted to show the problem with
reseting the setting.
Specify undefined as the value seems fine as long as undefined as a option
property value always means the same as that property being absent.
Alternatively, you could accept an optional second argument to derive that is
an array of property names to delete. Does this really occur enough to bother
with any of this. If this scenario is rare why not just not support this style
of derivation. BTW, contrary to a literal interpretation of actual language
you use above, I assume that new DTF(options) and dtf.derive(options) both
create a new dtf object.
The question is - do we keep derive methods? If so, do we care about this
case/my solution (since user has other ways to create the object)?
If the same thing can be accomplished other ways and it isn't a common usage
case then I recommend dropping it.
4. Should we rename LocaleInfo.collator()/numberFormat()/dateTimeFormat()
into LocaleInfo.createCollator()...? It makes it clear we are creating new
object.
The methods on the LocaleInfo constructor or are they really
LocaleInfo.prototype methods. In other words are the results derived from a
specific LocaleInfo instance or is the result some sort of global value that is
independent of the instances. If the latter, why are they associated with the
LocaleInfo constructor?
5. I think that calendar settings for DateTimeFormat doesn't bring much value
and makes implementation more complex. Overriding default calendar is rare
operation, and can be easily done with -u-ca extension - one just needs to
create new locale.
6. I would rename dateSkeleton into skeleton in DateTimeFormat settings.
--
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
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 fonts makes for a really hideous triangle. It doesn't line up at all with the top and bottom of the less-than/greater-than symbols. 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. Yeah. In fact, the analogy to type theory would have us read the : symbol as a binary predicate, which isn't what's going on here at all. So... I don't find either of these lexemes very pleasant, but I don't have any beautiful alternatives to offer. Dave It's highly variable, but on average they both generally look better in a mono-spaced fonts. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
4. Should we rename LocaleInfo.*collator*()/*numberFormat*()/* dateTimeFormat*() into LocaleInfo.*createCollator*()...? It makes it clear we are creating new object. The methods on the LocaleInfo constructor or are they really LocaleInfo.prototype methods. In other words are the results derived from a specific LocaleInfo instance or is the result some sort of global value that is independent of the instances. If the latter, why are they associated with the LocaleInfo constructor? They are prototypes: LocaleInfo.prototype.collator() I propose LocaleInfo.prototype.createCollator() since they actually create a new LocaleInfo.Collator (or DateTimeFormat or NumberFormat) objects based on that locale info. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Full Unicode strings strawman
On 05/16/11 11:11, Allen Wirfs-Brock wrote: I tried to post a pointer to this strawman on this list a few weeks ago, but apparently it didn't reach the list for some reason. Feed back would be appreciated: http://wiki.ecmascript.org/doku.php?id=strawman:support_full_unicode_in_strings Allen Two different languages made different decisions on how to approach extending their character sets as Unicode evolved: - Java kept their strings encoded exactly as they were (a sequence of 16-bit code units) and provided extra APIs for the cases where you want to extract a code point. - Perl widened the concept of characters in strings away from bytes to full Unicode characters. Thus a UTF-8 string can be either represented where each byte is one Perl character or where each Unicode character is one Perl character. There are conversion functions provided to move between the two. My experience is that Java's approach worked, while Perl's has led to an endless shop of horrors. The problem is that different APIs expect different kinds of strings, so I'm still finding places where conversions should be added but weren't (or vice versa) in a lot of code years after it was written. 1. I would not be in favor of any approach that widens the concept of a string character or introduces two different representations for a non-BMP character. It will suffer from the same problems as Perl, except that they will be harder to find because use of non-BMP characters is relatively rare. 2. Widening characters to 21 bits doesn't really help much. As stated earlier in this thread, you still want to treat clumps of combining characters together with the character to which they combine, worry about various normalized forms, etc. All of these require the machinery to deal with clumps of code units as though they were single characters/graphemes/etc., and once you have that machinery you can reuse it to support non-BMP characters while keeping string code units 16 bits. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
On May 18, 2011, at 3:35 PM, Nebojša Ćirić wrote: 4. Should we rename LocaleInfo.collator()/numberFormat()/dateTimeFormat() into LocaleInfo.createCollator()...? It makes it clear we are creating new object. The methods on the LocaleInfo constructor or are they really LocaleInfo.prototype methods. In other words are the results derived from a specific LocaleInfo instance or is the result some sort of global value that is independent of the instances. If the latter, why are they associated with the LocaleInfo constructor? They are prototypes: LocaleInfo.prototype.collator() I propose LocaleInfo.prototype.createCollator() since they actually create a new LocaleInfo.Collator (or DateTimeFormat or NumberFormat) objects based on that locale info. It could go either way and there isn't a lot of relevant precedent in the ES built-in libraries to guide this. If it is essential an characteristic that a new object is being created I personally would be inclined to put something in the name to indicate that. Personally I might use newXXX rather than createXXX. The other possibility is that you could make them be constructor functions so you would say: var myDtf = new myLocale.DateTimeFormat(myOptions); Since any native ES function can be used as a constructor (and will even do the right thing if it is carefully code with that possibility in mind) I guess that might argue for the non-imperative naming, particularly if it starts with an upper case. Then either the above or var myDtf = myLocale.DateTimeFormat(myOptions); would be equivalent. I think they both read fine. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScripts tests regarding SES
[+ankur, joe, arjun, shriram, ulfar, mitchell, shap] On Wed, May 18, 2011 at 1:54 PM, David Bruant david.bru...@labri.fr wrote: Hi, This message regards Secure ECMAScript (SES) [1] (by the way, can links like [2], [3] or [4] be added to the ses wiki page?). Good suggestion. I will do so. For your [4], SES development has moved to http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/. I will update the wiki and the es-lab site to make that clear. I may not get to either until after the May meeting. SES requires initSES.js to run. An environment where this happens is called Secureable EcmaScript 5 (please correct if I misunderstand or misuse the terminology). Ideally that would be right, and we hope will be right once browsers come into more complete ES5 conformance. The current SES development includes various so-called kludge switches. From http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/es5shim.js#33 : /// KLUDGE SWITCHES /// / // The following are only the minimal kludges needed for the current // Firefox, Safari, or the current Chrome Beta. At the time of // this writing, these are Firefox 4.0, Safari 5.0.4 (5533.20.27) // and Chrome 12.0.742.12 dev // As these move forward, kludges can be removed until we simply // rely on ES5. Each kludge switch indicates whether it preserves SES safety. For example, the first is: /** * Workaround for https://bugs.webkit.org/show_bug.cgi?id=55537 * * pThis kludge is safety preserving. * * pTODO(erights): Turning on this kludge is expensive, so we * should auto-detect at initialization time whether we need to on * this platform. */ //var TOLERATE_MISSING_CALLEE_DESCRIPTOR = false; var TOLERATE_MISSING_CALLEE_DESCRIPTOR = true; Regarding Securable ECMAScript 5, are there particular aspects of ES5 that would need to be tested in order to make sure not only that initSES.js runs but also does what is expected from it. Yes, absolutely. In other words, are there tests that could be added to Test262 in order to help ensuring an ES5 implementation is securable with very high confidence? Or is the current test suite sufficient? The current test suite is not sufficient. Regarding which tests to add, a good place to start is to look at the kludge-switch doc-comments in initSES, especially those in es5shim.js. But there are a large number of other issues I've been planning to write down and turn into tests. (I've been making some progress on these in Sputnik CLs, some of which I have yet to commit.) *More eyeballs would help here! *Please read the SES sources and Ankur's paper at http://www-cs-students.stanford.edu/~ataly/Papers/sp11.pdf which captures the reasoning and claims about SES's security, and try to spot any assumptions we're making that are not adequately tested by test262. Especially those that might be violated by some current implementations. Thanks! https://bugzilla.mozilla.org/show_bug.cgi?id=637994 causes a huge workaround in WeakMap.js but is documented only in a doc-comment in WeakMap.js not associated with a kludge switch, because I didn't want to include both versions in initSES.js. However, the current workaround is not safety preserving for reasons documented there (the identity stealing attack). This all brings up another maintenance issue not specific to SES. For each spec non-conformance, it would be nice to have a site, not necessarily the official test262 site, where it was easy to gather associations between failing tests and the corresponding bug threads of associated with the various major JS engines that have publicly accessible issue trackers. In particular, it would help answer the two questions: Are there any failing tests without corresponding open bugs? And are there any open bugs not demonstrated by corresponding failing tests? Even on a perfect Securable ES5 system, the kludge switch PATCH_MUTABLE_FROZEN_DATE_PROTO at http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/es5shim.js#111 would still be necessary because the bug here is in the ES5 spec, not in the implementations. In fact, AFAICT, all implementations correctly implement this part of the spec, and so faithfully create the vulnerability that the spec demands. This case is interesting because, even though there have been two world class efforts to formalize JS and do automated verification of security properties, where both of these efforts have poured over the ES3 and ES5 specs as a reference, and had real browsers to test against, that both these efforts missed this vulnerability. In fact, I am not aware of any previous JS security work that even noticed the issue. This should *NOT* be taken as a criticism of these efforts. It's just an important lesson in the kinds of confidence we should and should not derive from the
Re: i18n API implementation issues
On Wed, May 18, 2011 at 6:35 PM, Nebojša Ćirić c...@google.com wrote: 4. Should we rename LocaleInfo.*collator*()/*numberFormat*()/* dateTimeFormat*() into LocaleInfo.*createCollator*()...? It makes it clear we are creating new object. The methods on the LocaleInfo constructor or are they really LocaleInfo.prototype methods. In other words are the results derived from a specific LocaleInfo instance or is the result some sort of global value that is independent of the instances. If the latter, why are they associated with the LocaleInfo constructor? They are prototypes: LocaleInfo.prototype.collator() I propose LocaleInfo.prototype.createCollator() since they actually create a new LocaleInfo.Collator (or DateTimeFormat or NumberFormat) objects based on that locale info. Are they required to create new instance, or can they return a cached object that uses the same parameters? If the latter, then I would suggest either foo() or getFoo() rather than createFoo(). -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: prototype for operator proposal for review
It's okay in Courier New but not in lots of other popular monospaced fonts. See attached image. Dave inline: Screen shot 2011-05-18 at 4.19.01 PM.png 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 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 at all with the top and bottom of the less-than/greater-than symbols. 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. Yeah. In fact, the analogy to type theory would have us read the : symbol as a binary predicate, which isn't what's going on here at all. So... I don't find either of these lexemes very pleasant, but I don't have any beautiful alternatives to offer. Dave It's highly variable, but on average they both generally look better in a mono-spaced fonts. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
John,
I think you are correct. We allow for cached items, so it wouldn't be new
object we return in that case. I guess it's better to leave names as they
are now.
Allan,
this is how current proposal looks like (just parts relevant to
DateTimeFormat):
LocaleInfo = function(settings|string) {...}
LocaleInfo.prototype.dateTimeFormat(settings)
LocaleInfo.DateTimeFormat = function(settings, locale) {...}
LocaleInfo.DateTimeFormat.prototype.format(Date)
...
So one can do both:
var locale = new LocaleInfo();
var dtf = locale.dateTimeFormat({skeleton: 'MMMy'}); // shorthand for one
below
or
var dtf = new LocaleInfo.DateTimeFormat({skeleton: 'MMMy'}, locale});
18. мај 2011. 16.11, John Tamplin j...@google.com је написао/ла:
On Wed, May 18, 2011 at 6:35 PM, Nebojša Ćirić c...@google.com wrote:
4. Should we rename LocaleInfo.*collator*()/*numberFormat*()/*
dateTimeFormat*() into LocaleInfo.*createCollator*()...? It makes it
clear we are creating new object.
The methods on the LocaleInfo constructor or are they really
LocaleInfo.prototype methods. In other words are the results derived from a
specific LocaleInfo instance or is the result some sort of global value that
is independent of the instances. If the latter, why are they associated with
the LocaleInfo constructor?
They are prototypes:
LocaleInfo.prototype.collator()
I propose
LocaleInfo.prototype.createCollator()
since they actually create a new LocaleInfo.Collator (or DateTimeFormat or
NumberFormat) objects based on that locale info.
Are they required to create new instance, or can they return a cached
object that uses the same parameters? If the latter, then I would suggest
either foo() or getFoo() rather than createFoo().
--
John A. Tamplin
Software Engineer (GWT), Google
--
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
18. мај 2011. 16.48, Allen Wirfs-Brock al...@wirfs-brock.com је
написао/ла:
On May 18, 2011, at 4:33 PM, Nebojša Ćirić wrote:
John,
I think you are correct. We allow for cached items, so it wouldn't be
new object we return in that case. I guess it's better to leave names as
they are now.
The the cached and potentially sharable instance immutable?
I think that's what we agreed at the last meeting, to prevent potential
problems.
Allan,
this is how current proposal looks like (just parts relevant to
DateTimeFormat):
LocaleInfo = function(settings|string) {...}
LocaleInfo.prototype.dateTimeFormat(settings)
LocaleInfo.DateTimeFormat = function(settings, locale) {...}
LocaleInfo.DateTimeFormat.prototype.format(Date)
...
So one can do both:
var locale = new LocaleInfo();
var dtf = locale.dateTimeFormat({skeleton: 'MMMy'}); // shorthand for
one below
or
var dtf = new LocaleInfo.DateTimeFormat({skeleton: 'MMMy'}, locale});
I think you should only support one or the other (and I would go with the
version on the prototype). By having both you effective double the surface
area of this part of the API., but for what benefit? It isn't clear that
the connivence in a few situations justify the cost of developers having to
learn a larger API set.
Particularly if the above example is typical, I don't see why anyone would
ever code the second form. You still have to have locale available and the
first form is shorter.
If I remove constructor LocaleInfo.DateTimeFormat where would I put
LocaleInfo.DateTimeFormat.prototype.format() method for example (I would
gladly remove the duplication, but I am not sure how)? Right now I do:
LocaleInfo.prototype.dateTimeFormat(settings) {
return new LocaleInfo.DateTimeFormat(settings, this);
}
and
LocaleInfo.DateTimeFormat = function(settings, locale) {
}
does actual work of creating the new object.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
Just sort of curious... Given the following:
// old and busted
function SomeClass() {}; SomeClass.prototype.someMethod = function(arg) {
... }
// new hotness
class SomeClass { someMethod(arg) { ... } }
In the second form, how would I denote a method that is defined as an own
property? Additionally, how would something like the following be handled?
function Ctor() {
this.method = function() {
return own property;
};
return this;
}
Ctor.prototype.method = function() {
return instance property;
};
var c = new Ctor();
console.log(
c.method() // own property
);
Thanks in advance :)
Rick
On Wed, May 18, 2011 at 3:10 PM, Bob Nystrom rnyst...@google.com wrote:
On Wed, May 18, 2011 at 11:48 AM, Brendan Eich bren...@mozilla.comwrote:
The whole of class declaration is a mouthful. 'function' and 'prototype'
are overlong too.
Agreed. One of the reasons I'm really excited about this proposal is that
it addresses those:
// old and busted
function SomeClass() {}; SomeClass.prototype.someMethod = function(arg) {
... }
// new hotness
class SomeClass { someMethod(arg) { ... } }
We can try for conciseness in this one corner but it doesn't help in
general. I think we need to weight the whole syntax and see where the
verbosity *and other* pain points are in practice.
Sure. I'm not stuck on new, but in the chunks of sample code I've put
together using constructor (which is what Traceur uses/did use for a good
while) it did actually stick out as a syntactic wart, at least to me.
Same with 'constructor', and that property must exist somehow. Why not be
explicit and avoid having two names for one prototype property?
3 is false in ES5. Reserved identifiers are valid property names. This is
implemented in all the ES5-supporting browsers.
Ah, my mistake. These are both fair points. It's too bad constructor is
such a long word.
In the interests of considering all possibilities, one option would be to
use no name at all for the constructor:
class Point {
(x, y) {
this.x = x;
this.y = y;
}
}
I find that simultaneously delightfully lightweight and terrifyingly
obscure.
- bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
I believe it would be something like:
class Ctor {
public method() {
return own property;
}
method() {
return instance property;
}
}
By default, members within a class body are declared on the prototype.
Prefixing it with public places it on the new instance. Using public for
this isn't carved in stone yet, but some keyword means place the member
on the new instance and that prefix can be applied to any kind of member:
method, variable, constant, etc.
- bob
On Wed, May 18, 2011 at 5:07 PM, Rick Waldron waldron.r...@gmail.comwrote:
Just sort of curious... Given the following:
// old and busted
function SomeClass() {}; SomeClass.prototype.someMethod = function(arg) {
... }
// new hotness
class SomeClass { someMethod(arg) { ... } }
In the second form, how would I denote a method that is defined as an own
property? Additionally, how would something like the following be handled?
function Ctor() {
this.method = function() {
return own property;
};
return this;
}
Ctor.prototype.method = function() {
return instance property;
};
var c = new Ctor();
console.log(
c.method() // own property
);
Thanks in advance :)
Rick
On Wed, May 18, 2011 at 3:10 PM, Bob Nystrom rnyst...@google.com wrote:
On Wed, May 18, 2011 at 11:48 AM, Brendan Eich bren...@mozilla.comwrote:
The whole of class declaration is a mouthful. 'function' and 'prototype'
are overlong too.
Agreed. One of the reasons I'm really excited about this proposal is that
it addresses those:
// old and busted
function SomeClass() {}; SomeClass.prototype.someMethod = function(arg) {
... }
// new hotness
class SomeClass { someMethod(arg) { ... } }
We can try for conciseness in this one corner but it doesn't help in
general. I think we need to weight the whole syntax and see where the
verbosity *and other* pain points are in practice.
Sure. I'm not stuck on new, but in the chunks of sample code I've put
together using constructor (which is what Traceur uses/did use for a good
while) it did actually stick out as a syntactic wart, at least to me.
Same with 'constructor', and that property must exist somehow. Why not be
explicit and avoid having two names for one prototype property?
3 is false in ES5. Reserved identifiers are valid property names. This is
implemented in all the ES5-supporting browsers.
Ah, my mistake. These are both fair points. It's too bad constructor is
such a long word.
In the interests of considering all possibilities, one option would be to
use no name at all for the constructor:
class Point {
(x, y) {
this.x = x;
this.y = y;
}
}
I find that simultaneously delightfully lightweight and terrifyingly
obscure.
- bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
Nebojša--
My votes, for whatever they may be worth...
1. For LocaleInfo I would like to include construction with plain string:
new LocaleInfo(de) vs more verbose new LocaleInfo({'languageID': 'de'})
One would be able to construct LocaleInfo like this:
LocaleInfo(); - default
LocaleInfo('sr');
LocaleInfo({}); - default
LocaleInfo({'languageID': 'sr', 'regionID': 'RU'); - and all variations
(missing regionID, missing languageID).
That seems appropriate to me.
2. Language matching - how detailed should we go in specifying language
matching process?
I think you should strive to define this precisely, unless it's going to put an
undue burden on some subset of implementers. But I think you want to find a
precedent and stay as close to it as possible. You want to avoid reinventing
wheels.
3. Derive methods were introduced to simplify creation of objects by tweaking
current settings. It works well when you override existing setting or when you
add new one. It's not so great when you want to remove a setting. For example:
The question is - do we keep derive methods? If so, do we care about this
case/my solution (since user has other ways to create the object)?
I'm going to have to take another look at the strawman (the current version
you're working from is posted somewhere, right?), but I think there's some
value here and that your suggestion of using undefined seems reasonable.
Just the same, it'd be better if the derive() method were smart enough to know
that specifying dateType isn't going to do anything unless it also un-defines
skeleton. Otherwise, the developer has to remember that, or discover it the
hard way.
4. Should we rename LocaleInfo.collator()/numberFormat()/dateTimeFormat() into
LocaleInfo.createCollator()...? It makes it clear we are creating new object.
Yes.
5. I think that calendar settings for DateTimeFormat doesn't bring much value
and makes implementation more complex. Overriding default calendar is rare
operation, and can be easily done with -u-ca extension - one just needs to
create new locale.
Probably better to just use the locale, unless that's going to cause an undue
burden for implementers. (From my perspective, I'm trying to implement this on
top of ICU, and would prefer whatever forces me to write the least amount of
code above and beyond what ICU provides.)
6. I would rename dateSkeleton into skeleton in DateTimeFormat settings.
I don't really care.
As I said, for whatever it's worth...
--Rich Gillam
Lab126
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
On Wed, May 18, 2011 at 5:17 PM, Bob Nystrom rnyst...@google.com wrote:
I believe it would be something like:
class Ctor {
public method() {
return own property;
}
method() {
return instance property;
}
}
By default, members within a class body are declared on the prototype.
Prefixing it with public places it on the new instance. Using public for
this isn't carved in stone yet, but some keyword means place the member
on the new instance and that prefix can be applied to any kind of member:
method, variable, constant, etc.
Not quite. Per-instance member initialization only happens in the
constructor, because the values of per-instance properties is generally data
dependent on constructor parameters. The public (or whatever) and
private declarations only prefix ForwardDeclarations, which are generally
just comma separated lists of identifiers. The initialization in the
constructor happens in the traditional ES5 imperative manner. Also, the
public list is optional. It serves only a documentary purpose. So
class Ctor {
public method; // optional forward declaration of own property
method() {
return instance property;
}
constructor() {
this.method = function() {
return own property;
};
}
}
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
On May 18, 2011, at 5:06 PM, Nebojša Ćirić wrote:
If I remove constructor LocaleInfo.DateTimeFormat where would I put
LocaleInfo.DateTimeFormat.prototype.format() method for example (I would
gladly remove the duplication, but I am not sure how)? Right now I do:
LocaleInfo.prototype.dateTimeFormat(settings) {
return new LocaleInfo.DateTimeFormat(settings, this);
}
and
LocaleInfo.DateTimeFormat = function(settings, locale) {
}
does actual work of creating the new object.
Clearly I'm being sloppy by having first not read your entire API; but of
course actually developer also probably will jump in without reading everything
so may it isn't such a bad approach
I would expect that the LocaleInfo instance you obtained (I'll call it locale)
has been instantiate for some specific locale (in quotes I mean the abstract
concept of some specific locale). In other words locale encapsulates all the
knowledge that is needed to perform operations in some specific locale
context. Part of that encapsulated knowledge is what kind of DTF to use by
default for that locale or how to selection from a set of possible DTFs based
upon requested settings. In practice you might only have one class that
implements DTF or you might have several but that really is an implementation
that should be hidden inside locale.
I would then expect to see an implementation something like this:
LocaleInfo.prototype.dateTimeFormat(settings) {
return new this.__internalDTFProvider(settings, this)
}
Now that I have written this, I see the more concise answer:
The concrete class that implements a specific DTF should be a private
implementation detail. It doesn't have to have a public constructor API
because the constructor is called from within the dateTimeFormat method. The
instances of such private DTF constructors support the public DTF instance API.
In other words that have methods such as format. The actual implementation of
format would hang-off of the prototype object associated with such private DTF
constructors.
Here is a third way to state it:
LocaleInfo is a constructor that has a public API that is used to create (or
access) LocaleInfo objects.
localeInfo instances have a public API (essentially the public properties of
LocaleInfo.prototype) that give access to various kinds of objects including
objects that support the DTF interface
DTF objects implement the DTF public API including format
The constructor(s) for DTF objects is an implementation detail and doesn't need
a public API
allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
On Wed, May 18, 2011 at 5:51 PM, Mark S. Miller erig...@google.com wrote:
On Wed, May 18, 2011 at 5:17 PM, Bob Nystrom rnyst...@google.com wrote:
I believe it would be something like:
class Ctor {
public method() {
return own property;
}
method() {
return instance property;
}
}
By default, members within a class body are declared on the prototype.
Prefixing it with public places it on the new instance. Using public for
this isn't carved in stone yet, but some keyword means place the
member on the new instance and that prefix can be applied to any kind of
member: method, variable, constant, etc.
Not quite. Per-instance member initialization only happens in the
constructor, because the values of per-instance properties is generally data
dependent on constructor parameters. The public (or whatever) and
private declarations only prefix ForwardDeclarations, which are generally
just comma separated lists of identifiers. The initialization in the
constructor happens in the traditional ES5 imperative manner. Also, the
public list is optional. It serves only a documentary purpose. So
class Ctor {
public method; // optional forward declaration of own property
method() {
return instance property;
}
constructor() {
this.method = function() {
return own property;
};
}
}
Ah, OK. While it isn't necessary, it would be really convenient to be able
to create per-instance properties by providing an initializer in the class
body if those properties don't depend on this or ctor params:
class Point {
public x = 0, y = 0;
}
let p = new Point();
p.x; // 0
- bob
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API implementation issues
One more question wrt. private implementation.
Is it enough if I name it say LocaleInfo.DateTimeFormat__ and not include it
in the public API list in the proposal?
Looking around web I found ways to make things truly private, but there was
price to pay (see
http://stackoverflow.com/questions/55611/javascript-private-methods).
18. мај 2011. 17.55, Allen Wirfs-Brock al...@wirfs-brock.com је
написао/ла:
On May 18, 2011, at 5:06 PM, Nebojša Ćirić wrote:
If I remove constructor LocaleInfo.DateTimeFormat where would I put
LocaleInfo.DateTimeFormat.prototype.format() method for example (I would
gladly remove the duplication, but I am not sure how)? Right now I do:
LocaleInfo.prototype.dateTimeFormat(settings) {
return new LocaleInfo.DateTimeFormat(settings, this);
}
and
LocaleInfo.DateTimeFormat = function(settings, locale) {
}
does actual work of creating the new object.
Clearly I'm being sloppy by having first not read your entire API; but of
course actually developer also probably will jump in without reading
everything so may it isn't such a bad approach
I would expect that the LocaleInfo instance you obtained (I'll call it
locale) has been instantiate for some specific locale (in quotes I mean
the abstract concept of some specific locale). In other words locale
encapsulates all the knowledge that is needed to perform operations in some
specific locale context. Part of that encapsulated knowledge is what kind
of DTF to use by default for that locale or how to selection from a set of
possible DTFs based upon requested settings. In practice you might only
have one class that implements DTF or you might have several but that
really is an implementation that should be hidden inside locale.
I would then expect to see an implementation something like this:
LocaleInfo.prototype.dateTimeFormat(settings) {
return new this.__internalDTFProvider(settings, this)
}
Now that I have written this, I see the more concise answer:
The concrete class that implements a specific DTF should be a private
implementation detail. It doesn't have to have a public constructor API
because the constructor is called from within the dateTimeFormat method.
The instances of such private DTF constructors support the public DTF
instance API. In other words that have methods such as format. The actual
implementation of format would hang-off of the prototype object associated
with such private DTF constructors.
Here is a third way to state it:
LocaleInfo is a constructor that has a public API that is used to create
(or access) LocaleInfo objects.
localeInfo instances have a public API (essentially the public properties
of LocaleInfo.prototype) that give access to various kinds of objects
including objects that support the DTF interface
DTF objects implement the DTF public API including format
The constructor(s) for DTF objects is an implementation detail and doesn't
need a public API
allen
--
Nebojša Ćirić
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
On May 18, 2011, at 5:57 PM, Bob Nystrom wrote:
class Point {
public x = 0, y = 0;
}
let p = new Point();
p.x; // 0
This is pretty rare, in my experience. A hard case? If the constructor does set
x and y from parameters, then you have double-initialization. If some
properties are non-writable, you can't do this. YAGNI?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: I noted some open issues on Classes with Trait Composition
On Wed, May 18, 2011 at 4:10 PM, Bob Nystrom rnyst...@google.com wrote:
On Wed, May 18, 2011 at 11:48 AM, Brendan Eich bren...@mozilla.com
wrote:
The whole of class declaration is a mouthful. 'function' and 'prototype'
are overlong too.
Sure. I'm not stuck on new, but in the chunks of sample code I've put
together using constructor (which is what Traceur uses/did use for a good
while) it did actually stick out as a syntactic wart, at least to me.
Same with 'constructor', and that property must exist somehow. Why not be
explicit and avoid having two names for one prototype property?
3 is false in ES5. Reserved identifiers are valid property names. This is
implemented in all the ES5-supporting browsers.
Ah, my mistake. These are both fair points. It's too bad constructor is
such a long word.
Nowadays most libraries that implement some sort of class wrapping use
lengthy names for the constructor and it's not that bad.
Mootools
var Cat = new Class({
initialize: function(name){
this.name = name;
}
});
Prototype
var Cat = Class.create({
initialize: function(name){
this.name = name;
}
});
Dojo
var Cat = dojo.declare(null, {
constructor: function(name){
this.name = name;
}
});
YUI
var Cat = Y.Base.create('cat', null, [], {
initializer: function(name){
this.name = name;
}
});
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
