ES4 draft: Function
First draft of the spec for the Function class. Please comment.
--lars
Title: The class "Function"
The class Function
NAME: "The class 'Function'"
FILE: spec/library/Function.html
CATEGORY: Pre-defined classes
SOURCES:REFERENCES [1], [2], [3], [5]
SPEC AUTHOR:Lars
DRAFT STATUS: DRAFT 1 - 2008-03-10
REVIEWED AGAINST ES3: YES
REVIEWED AGAINST ERRATA:YES
REVIEWED AGAINST BASE DOC: YES
REVIEWED AGAINST PROPOSALS: YES
REVIEWED AGAINST CODE: YES
REVIEWED AGAINST TICKETS: YES
IMPLEMENTATION STATUS: ES4RI
TEST CASE STATUS: ?
OPEN ISSUES
* ES3 restrictions on argArray having to be an Array or an arguments
object in Function.prototype.apply have been removed here.
NOTES
* The annotation '/*: function*/' below looks like that because the
reference implementation does not yet accept plain 'function' as a
type annotation to mean 'anything callable' (ticket #153).
* The use of 'Private' instead of 'private' is a workaround for a
bug in the reference implementation (#368).
REFERENCES
[1] ECMAScript 3rd Edition specification section 15.3
[2] http:wiki.ecmascript.org/doku.php?id=proposals:static_generics
[2] http:bugs.ecmascript.org/ticket/172
[4] http:bugs.ecmascript.org/ticket/173
[5] http:bugs.ecmascript.org/ticket/174
The class Function is a dynamic, non-final, direct subclass of
Object (see class Object).
All objects defined by function definitions or expressions in
ECMAScript are instances of the class Function.
Not all objects that can be called as functions are instances of
subclasses of the Function class, however. Any object that has a
meta::invoke method can be called as a function.
NOTE Host functions may also not be instances of Function or its
subclasses, but must to some extent behave as if they are (see Host objects). However, host functions need not provide
meta::invoke methods to be callable. The type function,
defined elsewhere, matches invokable host functions even if they do
not have a meta::invoke method.
Synopsis
The class Function provides the following interface:
dynamic class Function extends Object
{
public function Function(...args)
static meta function invoke(...args)
static public function apply(fn /*: function*/, thisArg: Object=null, argArray: Object=null)
static public function bind(method /*: function*/, thisObj: Object=null, ...args)
static public function call(fn /*: function*/, thisObj: Object=null, ...args)
static public const length = 1
meta final function invoke( )
override intrinsic function toString() : string
intrinsic function apply(thisArg: Object=null, argArray: Object=null)
intrinsic function bind(thisObj: Object=null, ...args)
intrinsic function call(thisObj: Object=null, ...args)
public const length =
public var prototype =
}
The Function prototype object provides these direct properties:
meta::invoke: function ()
length: 0
toString: function ()
apply:function(thisArg, argArray)
bind: function(thisArg, ...args)
call: function(thisArg, ...args)
Methods on the Function class object
new Function (p1, p2, , pn, body)
Description When the Function constructor is called with some arguments
as part of a new _expression_, it creates a new Function
instance whose parameter list is given by the concatenation of the
pi arguments separated by "," and whose executable code
is given by the body argument.
There may be no pi arguments, and body is optional too,
defaulting to the empty string.
If the first character of the comma-separated concatenation of the
pi is a left parenthesis then the list of parameters
must be parseable as a FormalParameterListopt enclosed
in parentheses and optionally followed by a colon and a return type.
Otherwise, the list of parameters must be parsable as a
FormalParameterListopt.
If the list of parameters is not parseable as outlined in the
previous two paragraphs, or if the body is not parsable as a
FunctionBody, then a SyntaxError exception is thrown (see the
grammar in section ECMAScript grammar).
Regardless of the form of the parameter list, it may include type
annotations, default parameter values, and rest arguments.
Returns The Function constructor returns a new Function instance.
Implementation
public function Function(...args)
helper::createFunction(args);
helper function createFunction(args) {
let parameters = "";
let body = "";
if (args.length > 0) {
body = args[args.length-1];
args.length = args.length-1;
parameters = args.join(",");
}
body = string(body);
magic::initializeFunction(this, __ES4__::global, parameters, body);
}
The magic function initializeFunction initializes the function
object this from the list of
RE: ES4 draft: Object
Draft 2 of the spec for the Object class. Changelog near the beginning.
--lars
Title: The class "Object"
The class Object
NAME: "The class 'Object'"
FILE: spec/library/Object.html
CATEGORY: Pre-defined classes (E262-3 Chapter 15)
SOURCES:REFERENCES [1], [2]
SPEC AUTHOR:Lars
DRAFT STATUS: DRAFT 2 - 2008-03-10
REVIEWED AGAINST ES3: YES
REVIEWED AGAINST ERRATA:YES
REVIEWED AGAINST BASE DOC: YES
REVIEWED AGAINST PROPOSALS: YES
REVIEWED AGAINST CODE: YES
IMPLEMENTATION STATUS: ES4RI
TEST CASE STATUS: ?
CHANGES SINCE DRAFT 1 (2008-03-05)
* More elaborate status block above
* Prototype methods do not delegate to the corresponding intrinsic
methods, but to shared private methods that are also called by the
intrinsic method. In this fashion, prototype method behavior is
invariant of subclassing.
* Introduction of a specification-only protocol helper::getClassName
for overriding class names for ES3 compatibility.
NOTES
* The use of 'Private' instead of 'private' below is a workaround
for a bug in the reference implementation (#368).
* The function 'helper::toEnumerableId' converts an arbitrary value
to a member of 'EnumerableId': int, uint, string, or Name. It is
specified elsewhere but in general you can think of it as
converting any number to int or uint, leaving strings and Names
alone, and converting everything else to string.
REFERENCES
[1] [1] http:wiki.ecmascript.org/doku.php?id=proposals:enumerability
[2] builtins/Name.es in the ES4 RI
The class Object is a dynamic non-final class that does not
subclass any other objects: it is the root of the class hierarchy.
All values in ECMAScript except undefined and null are
instances of the class Object or one of its subclasses.
NOTE Host objects may not be instances of Object or its
subclasses, but must to some extent behave as if they are (see Host objects).
Synopsis
The class Object provides this interface:
public dynamic class Object
{
public function Object(value=undefined)
static meta function invoke(value=undefined)
static public const length = 1
intrinsic function toString() : string
intrinsic function toLocaleString() : string
intrinsic function valueOf() : Object
intrinsic function hasOwnProperty(name: EnumerableId): boolean
intrinsic function isPrototypeOf(value): boolean
intrinsic function propertyIsEnumerable(name: EnumerableId, flag: (boolean|undefined) = undefined): boolean
}
The Object prototype object provides these direct properties:
toString: function () ,
toLocaleString: function () ,
valueOf: function () ,
hasOwnProperty: function (name) ,
isPrototypeOf:function (value) ,
propertyIsEnumerable: function (name, flag=undefined) ,
The Object prototype object is itself an instance of the class
Object, with the exception that the value of its [[Prototype]]
property is null.
Methods on the Object class object
newObject(value=)
Description When the Object constructor is called with an argument
value (defaulting to undefined) as part of a new
_expression_, it transforms the value to an object in a way that
depends on the type of value.
Returns The Object constructor returns an object (an instance of
Object or one of its subclasses, or a host object).
NOTE The Object constructor is the only constructor function
defined on a class in the language whose result may be a value of a
different class than the one in which the constructor is defined.
Implementation The Object constructor can't be expressed as a regular
ECMAScript constructor. Instead it is presented below as a helper
function makeObject that the ECMAScript implementation will invoke
when it evaluates new Object.
The helper function makeObject only is invoked on native ECMAScript
values. If new Object is evaluated on a host object, then actions
are taken and a result is returned in an implementation dependent
manner that may depend on the host object.
helper function makeObject(value=undefined) {
switch type (value) {
case (s: string) {
return new String(s);
}
case (b: boolean) {
return new Boolean(b);
}
case (n: (int|uint|double|decimal)) {
return new Number(n);
}
case (x: (null|undefined)) {
return magic::createObject();
}
case (o: Object) {
return o;
}
}
}
Object(value=)
Description When the Object class object is called as a function with zero
or one arguments it performs a type conversion.
Returns It returns the converted value.
Implementation
static meta function invoke(value=undefined)
new Object(value);
Methods on Object instances
The intrinsic methods on Object instances delegate to private
methods that are also
Re: ES4 draft: Object
On 10/03/2008, Lars Hansen [EMAIL PROTECTED] wrote: Draft 2 of the spec for the Object class. Changelog near the beginning. The draft HTML seems a little broken. There's amp;#x0085 in it early on, later these appear raw in the source (which displays as an empty square in Opera and IE8). And near the end of the document you have /p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/div Slightly broken conversion tool? -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Function
What is the reason to make the thisObj param to bind optional? 2008/3/10 Lars Hansen [EMAIL PROTECTED]: First draft of the spec for the Function class. Please comment. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
Brendan Eich wrote:
On Mar 9, 2008, at 3:01 PM, Yuh-Ruey Chen wrote:
Brendan Eich wrote:
ES3 code can't detect namespaces, so arguably shouldn't care if we
were to implement DontEnum using an open namespace. But this could be
a problem for mixed ES3 and ES4 scenarios where the ES4 code does
introspect via Name objects and is surprised to find ES3 objects
with qualified property names.
I'm talking about how the enumerability (or lack thereof) of
Object.prototype.* are determined. Or are prototype methods also not
enumerable by default like fixtures?
My reply was not meant to be an answer, but a question: should we
drop this dontenum-namespace idea because it will break ES3+ES4
mixtures where the ES4 code reflects on a property's namespace
qualifier by using a Name object?
Does this included ES3-style prototype methods? And would it
be possible to init a fixture to be enumerable?
In the sketch I mailed, you didn't see any mention of fixtures --
IIRC you asked about them in reply. Just to explain what my proposal
was aiming to do: It seems to me that if we have to add a magic bit
back into the skinny is-it-enumerable decision tree, we may as well
keep DontEnum.
And the RI does print
it, so I'm not sure what you're talking about.
The RI is (a) not normative (nothing apart from ES3+fixes is yet),
(b) based on a DontEnum attribute model, not on my proposal. Not sure
why you thought I was talking about it. I was making a new proposal.
Ok, that cleared things up a bit. I didn't realize you were making a
proposal and asking questions based off it :) I thought you were
mentioning how the RI was implemented today at the moment.
Can you elaborate on cases where ES4 code does introspect via Name
objects and is surprised to find ES3 objects with qualified property
names.? I can't think of any.
BTW, what exactly is a fixture?
That's a good question, and it seems the answer is not in the wiki.
Trying the trac:
http://bugs.ecmascript.org/ticket/233
which references the overview document.
In ES3 terms, a fixture is a property with the DontDelete attribute set.
But there's more to it than that, for reasons expanded on in #233 to
do with namespace lookup and early binding. And there is another case
that Lars pointed out recently to do with dynamic classes, but I'll
avoid trying to summarize it except to say that a fixture is a fixed
property that can't be deleted or shadowed.
Thanks, that's a good summary, though some of the commentary in the
ticket was confusing (like lth's example - was x.toString decided to be
ambiguous?).
Is that the right design?
dynamic class C {
public var fixture;
function C() { this.expando = 42; }
}
for (var i in new C)
intrinsic::print(i);
wouldn't you expect to see expando printed? Is it printed because
the default namespace for expando is the public-default one? I
believe it is not, in the current proposal and the RI. Rather, each
class or package gets a nonce-named public namespace, different from
every other such per-class or per-package public. IIRC package trumps
class -- classes within a package share the package's nonce-named
public namespace (Jeff, Lars, please correct me if I'm wrong).
I meant non-expando vars and methods defined within the class,
whatever
the terminology is used (I see 'fixture' thrown around everywhere), are
not enumerable. So yes, expando should be printed.
From your numbered steps above, step 3 must have been reached -- so
expando is in the public-public (null qualifier in Name object
reflection) namespace. Not in the class-C-public namespace. My
question is whether that is the right design choice.
Are they any particular disadvantages that you can think of? Maybe
another ES4 designer can chime in here.
BTW, a bit off topic: if a class is defined in a namespace, are the
properties of that class also defined in that namespace (instead of just
public/class-public)? Namespaces aren't clearly specified in the wiki or
the overview, the tickets are unorganized, and the RI tends to barf when
it comes to them. Ugh, I feel Apple's pain when they complain that they
don't know where to start...
Are you saying that each
property is defined in a class-specific public namespace, and
therefore does not get enumerated? I would say that expando properties
should be defined in the global public namespace, so that they would
be enumerated.
Ok, I like that. I'm not arguing a side, just showing the choice.
There may be other cases, though, where a class-public property name
might want to be enumerable. In such a case the step 2 you wrote
would need to elaborate its public test. But again, my proposal was
about enumerability, independent of fixture-ness.
/be
Yeah, I asked whether it was possible to make a class-public property
enumerable. And if so, I really
Re: ES4 draft: Vector
new Vector.T ( length=..., fixed=... )
It would be helpful for readability to have the types here.
The |Vector| constructor is implementation-defined.
This is misleading. Usually when a standard states that something is
implementation-defined, it means that its semantics are not specified in the
standard. Having no standard-defined vector constructor would be strange
indeed.
If you merely don't want to write pseudo-code for the Vector constructor,
please just omit the Implementation section.
Vector( object )
When the |Vector| class object is called as a function, it creates a new
variable-length |Vector| object of type |*| ...
static meta function invoke(object) {
if (object is Vector.*)
return object;
The description and code don't match.
[Also, I'm a bit unclear about how parametrized types currently work. The
overview document has examples that seem to indicate that you call bound types
as functions. What happens when you call Vector.Foo as a function and pass
it a Vector.Bar?]
toLocaleString: This seems overspecified. Do you want to explicitly define
what happens if the vector is modified in the middle of running this?
concat:
VectorX cannot be a subtype of VectorY even if X is a subtype of Y. If it
were, the type system would be unsound: you could pass a VectorX to a
function F expecting a VectoryY and then have F write a Y into that vector.
every, filter, etc.: These seem overspecified. For example, the definition of
filter states that the implementation must perform the lookup and fetch of each
found element twice, which unnecessarily forbids more efficient implementations.
forEach: Why is clamp here?
The static indexOf method ...: indexOf isn't a static method.
Why does indexOf return AnyNumber?
lastIndexOf: What happens when you do i-- on a uint with the value of 0? Do
you get 4294967295?
sort: Doesn't return anything.
splice:
if (items.length delcnt) {
let shift = delcnt - items.length;
for ( let n=0, i=first; n shift ; n++, i++ )
this[i] = this[i+shift];
length -= shift;
}
else {
let shift = items.length - delcnt;
for ( let n=shift-1, i=first+shift; n = 0 ; n--, i-- )
this[i] = this[i-shift];
}
Both of these seem wrong. I think there are at least four different errors
here.
unshift:
Need to raise length first.
for ( let i=0 ; i numitems ; i++ )
this[newlimit-i] = this[oldlimit-i];
The bounds on this loop are wrong.
1.4: Typo: defined on directly on
When you iterate through Maps, you get the old length if the Map is modified
during the iteration. When you iterate through Vectors, you get the new
length. The discrepancy seems jarring.
fixed should be a constant property or be removed altogether. It's useless as
a variable -- anybody can change the length of the vector at any time anyway,
and now code that hands out references to vectors to clients has to deal with
bozos who make those vectors fixed just for grins.
What happens if you try to index a vector with +Infinity or NaN? I assume it's
RangeError, but don't know enough about how numerically named properties work.
prototype function every(this:Vector.*, checker, thisObj=undefined)
(this.intrinsic::every(checker, thisObj is Object) ? thisObj : null);
prototype function filter(this:Vector.*, checker, thisObj=undefined)
(this.intrinsic::filter(checker, thisObj is Object) ? thisObj : null);
prototype function forEach(this:Vector.*, eacher, thisObj=undefined)
(this.intrinsic::forEach(checker, thisObj is Object) ? thisObj : null);
Why are you passing a boolean as the thisObj argument to intrinsic::every et
al.?
Waldemar
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Function
-Original Message- From: Erik Arvidsson [mailto:[EMAIL PROTECTED] Sent: 10. mars 2008 17:31 To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft: Function What is the reason to make the thisObj param to bind optional? Symmetry with call and apply and a consequence of the definition given in the proposals page (link below, it's near the bottom). But I agree that it seems misguided. Will change this unless there's opposition to it. http://wiki.ecmascript.org/doku.php?id=proposals:static_generics --lars 2008/3/10 Lars Hansen [EMAIL PROTECTED]: First draft of the spec for the Function class. Please comment. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
intrinsic function propertyIsEnumerable(name: EnumerableId, flag: (boolean|undefined) = undefined): boolean I too find the second parameter here abhorrent. Please find another way to solve it (Brendan's namespace idea maybe) or remove this feature altogether. How does property lookup deal with properties indexed by numbers that are not int or uint? toEnumerableId converts them to strings, but the Vector proposal indicated that vectors don't. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Object
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of liorean Sent: 10. mars 2008 17:52 To: es4-discuss@mozilla.org Subject: Re: ES4 draft: Object On 10/03/2008, Lars Hansen [EMAIL PROTECTED] wrote: Draft 2 of the spec for the Object class. Changelog near the beginning. ~~intrinsic::toString ( )~~ The intrinsic toString method returns the concatenation of [, object, the class name of the object, and ]. There should probably be a whitepace between object and the class name, as is the case in the implementation. There should. Corrected. ~~intrinsic::valueOf ( )~~ If the object is the result of calling the Object constructor with a host object (Host objects), it is implementation-defined whether valueOf returns its this value or another value such as the host object originally passed to the constructor. (Host objects) looks a bit weird like that. Should probably be either (see Host objects) analogously to how you later use (see HasProperty-defn) or reference style, [Host objects] Corrected. ~~intrinsic::isPrototypeOf ( value )~~ The function magic::getPrototype extracts the [[Prototype]] property from the object. See magic:getPrototype. And here a reference to documentation elsewhere. Probably should try to be consistent about how those look. I assume these are going to be links in the finished spec? The primary format of the final spec is word and/or pdf, so I don't know about links there. I hope that we can release an HTML version too, and obviously it would be good if there could be good hyperlinking there. I would like to promise all of that but I am not going to do it. However, there will at least be proper references to the sections that define the magic functions. In general the specification of the magic functions is somewhat unstructured at present. I appreciate this reminder about that :-) --lars -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft last call: line continuation in string and regex literals
The character sequence BACKSLASH lineterminator (where lineterminator will be one of the characters LF, LS, or PS) is removed from string literals delimited by either single or triple SINGLEQUOTE or DOUBLEQUOTE characters. (Triple-quoting is defined in [5].) This states that: abc\\ tde evaluates to the string abctabde. Is this really what we want? I'd find such nested escape sequences really strange. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 process tweaks
Jeff Dyer wrote: - Phone calls as needed Is there one tomorrow? There's a blank agenda page for it. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Object
-Original Message- From: Waldemar Horwat [mailto:[EMAIL PROTECTED] Sent: 10. mars 2008 18:50 To: Lars Hansen Cc: es4-discuss@mozilla.org Subject: Re: ES4 draft: Object intrinsic function propertyIsEnumerable(name: EnumerableId, flag: (boolean|undefined) = undefined): boolean I too find the second parameter here abhorrent. Please find another way to solve it (Brendan's namespace idea maybe) or remove this feature altogether. The feature was approved by the WG and solves a practical problem. If another way to solve this practical problem is proposed (in a more structured form than in the ongoing discussion) and finds favor with the WG, then fine -- of course we can replace it. Until then, this feature stays as it is until the WG can be convinced that it needs to be removed. Personally I think that it is ugly/abhorrent is a weak basis on which to remove the current feature. How does property lookup deal with properties indexed by numbers that are not int or uint? toEnumerableId converts them to strings, but the Vector proposal indicated that vectors don't. The intrinsic::hasOwnProperty and intrinsic::propertyIsEnumerable methods on Object require EnumerableId parameters, and no conversion happens automatically when they are called (there should be no automatic conversion to union types, even from a number to a number in the type). So programs trying to call the intrinsic methods on doubles (say) will receive errors. This is true independent of Vector. The prototype methods inherited from Object perform conversions explicitly, but can be overridden in Vector to prevent the conversion. Ergo the hasOwnProperty and propertyIsEnumerable methods on Vector should be able to handle arbitrary names, and should return false for all property names that are numbers not in the uint range -- if that's what we think is the desired behavior. That said, you raise a good point and I don't think the story is fully coherent yet. Certainly we don't have a working prototype of this. (And yet another point is that I expect that the int and uint types are not going to be in the final language and that some of the machinery in Object will have to be rethought as a consequence of that change.) --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft last call: line continuation in string and regex literals
-Original Message- From: Waldemar Horwat [mailto:[EMAIL PROTECTED] Sent: 10. mars 2008 18:59 To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft last call: line continuation in string and regex literals The character sequence BACKSLASH lineterminator (where lineterminator will be one of the characters LF, LS, or PS) is removed from string literals delimited by either single or triple SINGLEQUOTE or DOUBLEQUOTE characters. (Triple-quoting is defined in [5].) This states that: abc\\ tde evaluates to the string abctabde. Is this really what we want? I'd find such nested escape sequences really strange. That looks like an illegal token to me, since the lexer will read a b c \ and then see an unescaped linefeed. Since the speclet states nothing about changing the way strings are lexed, normal escape character processing should be in effect, and that dictates that \\ is processed into \ independently of what follows. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Object
As far as I can see this is not a problem in the file I sent out, nor in the one I received from the reflector. What mailer are you using? Anyone else see this? --lars -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of liorean Sent: 10. mars 2008 17:18 To: es4-discuss@mozilla.org Subject: Re: ES4 draft: Object On 10/03/2008, Lars Hansen [EMAIL PROTECTED] wrote: Draft 2 of the spec for the Object class. Changelog near the beginning. The draft HTML seems a little broken. There's amp;#x0085 in it early on, later these appear raw in the source (which displays as an empty square in Opera and IE8). And near the end of the document you have /p/p/p/p/p/p/p/p/p/p/p/p/p/p/p /p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p /p/p/p/p/p/p/p/p/p/p/p/p/p/p/p /p/p/p/p/p/p/p/p/p/p/p/p/p/p/p/p /p/p/p/p/p/p/p/p/div Slightly broken conversion tool? -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
No ES4-WG phone call (RE: ES4 process tweaks)
Waldemar Horwat wrote: Jeff Dyer wrote: - Phone calls as needed Is there one tomorrow? There's a blank agenda page for it. Hearing no objection, the ES4-WG weekly phone calls are suspended until sufficient need for one arises. Enjoy your free hour! Jd ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft last call: line continuation in string and regex literals
Lars Hansen wrote: The character sequence BACKSLASH lineterminator (where lineterminator will be one of the characters LF, LS, or PS) is removed from string literals delimited by either single or triple SINGLEQUOTE or DOUBLEQUOTE characters. (Triple-quoting is defined in [5].) This states that: abc\\ tde evaluates to the string abctabde. Is this really what we want? I'd find such nested escape sequences really strange. That looks like an illegal token to me, since the lexer will read a b c \ and then see an unescaped linefeed. Since the speclet states nothing about changing the way strings are lexed, normal escape character processing should be in effect, and that dictates that \\ is processed into \ independently of what follows. It's what we all want. As written, that's not what it states. This isn't ready to go in until this bug is corrected. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft last call: line continuation in string and regexliterals
-Original Message- From: [EMAIL PROTECTED] [mailto:es4-discuss- [EMAIL PROTECTED] On Behalf Of Waldemar Horwat Sent: Monday, March 10, 2008 6:29 PM To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft last call: line continuation in string and regexliterals Lars Hansen wrote: The character sequence BACKSLASH lineterminator (where lineterminator will be one of the characters LF, LS, or PS) is removed from string literals delimited by either single or triple SINGLEQUOTE or DOUBLEQUOTE characters. (Triple-quoting is defined in [5].) This states that: abc\\ tde evaluates to the string abctabde. Is this really what we want? I'd find such nested escape sequences really strange. That looks like an illegal token to me, since the lexer will read a b c \ and then see an unescaped linefeed. Since the speclet states nothing about changing the way strings are lexed, normal escape character processing should be in effect, and that dictates that \\ is processed into \ independently of what follows. It's what we all want. As written, that's not what it states. This isn't ready to go in until this bug is corrected. Waldemar, can you suggest a fix? Jd ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
On 11/03/2008, Lars Hansen [EMAIL PROTECTED] wrote: As far as I can see this is not a problem in the file I sent out, nor in the one I received from the reflector. What mailer are you using? Gmail's web interface. And checking, it appears only using the View link, not the Download link. So it appears to be GMail's fault. -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
Lars Hansen wrote: The feature was approved by the WG and solves a practical problem. If another way to solve this practical problem is proposed (in a more structured form than in the ongoing discussion) and finds favor with the WG, then fine -- of course we can replace it. Until then, this feature stays as it is until the WG can be convinced that it needs to be removed. Personally I think that it is ugly/abhorrent is a weak basis on which to remove the current feature. We are the WG. Are you saying that substantive discussions of your proposals are not welcome? Not sure what the point of participating is if that's the case. I'm dealing with a serious insurrection of folks who believe that the ES4 working group has a bad attitude, based on Brendan's public comments and responses to issues like this one. They're quite visible. Waldemar ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Function
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen Sent: 10. mars 2008 18:46 To: Erik Arvidsson Cc: es4-discuss Discuss Subject: RE: ES4 draft: Function -Original Message- From: Erik Arvidsson [mailto:[EMAIL PROTECTED] Sent: 10. mars 2008 17:31 To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft: Function What is the reason to make the thisObj param to bind optional? Symmetry with call and apply and a consequence of the definition given in the proposals page (link below, it's near the bottom). But I agree that it seems misguided. Will change this unless there's opposition to it. http://wiki.ecmascript.org/doku.php?id=proposals:static_generics But is null an acceptable non-default value for thisObj (meaning, use the global object in the bind method's scope)? --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Object
-Original Message- From: Waldemar Horwat [mailto:[EMAIL PROTECTED] Sent: 10. mars 2008 19:40 To: Lars Hansen Cc: es4-discuss@mozilla.org Subject: Re: ES4 draft: Object Lars Hansen wrote: The feature was approved by the WG and solves a practical problem. If another way to solve this practical problem is proposed (in a more structured form than in the ongoing discussion) and finds favor with the WG, then fine -- of course we can replace it. Until then, this feature stays as it is until the WG can be convinced that it needs to be removed. Personally I think that it is ugly/abhorrent is a weak basis on which to remove the current feature. We are the WG. Are you saying that substantive discussions of your proposals are not welcome? Not sure what the point of participating is if that's the case. Sorry, I didn't realize that I find it abhorrent qualified as substantive discussion. My fault. Won't happen again. I'm dealing with a serious insurrection of folks who believe that the ES4 working group has a bad attitude, based on Brendan's public comments and responses to issues like this one. They're quite visible. Debate is only good. I merely pointed out the obvious thing, namely that until there is an alternative proposal written up to deal with this issue, the current design stands unless the WG, as a group, decides to just get rid of it (leaving the problem it was designed to solve solution-less). I like the idea of making non-public-namespaced properties be not-enumerable and getting rid of DontEnum. We've talked loosely about it for a while. But it's remained loose talk, it has never made it to the stage where it is a coherent proposal. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: ES4 draft: Name
Draft 2, changelog near the beginning.
Please note the OPEN ISSUES section, which names two fairly
arbitrary designs in this proposal. Comments welcome.
--lars
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen
Sent: 5. mars 2008 17:32
To: es4-discuss@mozilla.org
Subject: ES4 draft: Name
Name objects represent reflected namespace::identifier pairs.
Here's the draft spec.
Comments welcome.
--lars
Title: The class "Name"
The class Name
NAME: "The class 'Name'"
FILE: spec/library/Name.html
CATEGORY: Pre-defined classes
SOURCES:REFERENCES [1], [2]
SPEC AUTHOR:Lars
DRAFT STATUS: DRAFT 2 - 2008-03-10
REVIEWED AGAINST ES3: N/A
REVIEWED AGAINST ERRATA:N/A
REVIEWED AGAINST BASE DOC: N/A
REVIEWED AGAINST PROPOSALS: YES
REVIEWED AGAINST CODE: YES
REVIEWED AGAINST TICKETS: YES
IMPLEMENTATION STATUS: ES4 RI
TEST CASE STATUS: ?
CHANGES SINCE DRAFT 1 (2008-03-05)
* Compatibility note in intro.
* More elaborate status block above.
* Prototype and intrinsic methods forward to private methods now.
* The Name constructor is allowed to hash-cons.
* The Name converter is required to return its first argument if it
is a Name object and the second parameter is undefined.
NOTES
* Due to an RI bug (#368), the namespace 'Private' is used instead
of 'private'.
OPEN ISSUES
* intrinsic::valueOf returns a string, but should it return the Name
object instead? (The original proposal returns a string.)
* The constructor accepts combinations of arguments deemed to be
useful (a convenient but restrained superset of the types in
EnumerableId). It's pretty ad-hoc, though. Any better proposals?
REFERENCES
[1] http:wiki.ecmascript.org/doku.php?id=proposals:name_objects
[2] builtins/Name.es in the ES4 RI
The class Name is a final, nullable, non-dynamic, direct
subclass of String that reflects a property name as a pair of
Namespace and string values.
COMPATIBILITY NOTE The Namespace class is new in the 4th Edition of this Standard.
Synopsis
The class Name provides the following interface:
__ES4__ final class Name extends String
{
public function Name(a, b=undefined)
static meta function invoke(a, b=undefined): Name
public static const length = 2
override intrinsic function toString() : string
override intrinsic function valueOf() : string
public const qualifier: Namespace
public const identifier: string
}
The Name prototype object provides the following direct properties:
toString: function (this: Name)
valueOf: function (this: Name)
Methods on the Name class object
newName(a,b=)
Description The Name constructor initializes a new Name object.
Various combinations of the two arguments a and b are allowed.
If a is a string, a Name, or an integer in the range
[0,232) then b must be undefined. Otherwise, if
a is a Namespace then b must be a string or an integer in
the range [0,232).
The Name constructor is not required to construct a new,
unique object every time it is called.
Implementation The Name constructor is implementation-dependent.
The helper function analyzeArgs, called by the Name
constructor, takes the two values a and b that were passed to
the Name constructor and returns an object containing a qualifier
in the form of a namespace (which may be null) and an identifier
in the form of a string. The qualifier and identifier are used to
create the Name object.
static helper function analyzeArgs (a, b) {
if (a is Namespace)
return analyzeWithNamespace(a, b);
if (b === undefined) {
if (a is Name)
return a;
return analyzeWithNamespace(null, a);
}
throw new TypeError();
function analyzeWithNamespace(ns, x) {
if (x is AnyNumber && isIntegral(x) && x > 0 && x = 0x || x is AnyString)
return { qualifier: ns, identifier: string(x) };
throw TypeError();
}
}
Name(a,b=)
Description When the Nameclass object called as a function it creates a
Name object. If a is a Name object and b is
undefined then a is returned. Otherwise, a Name object is
created by invoking the Name constructor on the parameters a
and b.
Returns The Name class object called as a function returns a
Name object.
Implementation
static meta function invoke(a, b=undefined): Name
new Name(a, b);
Methods on Name instances
intrinsic::toString()
Description The intrinsic toString method converts this Name object
to a string.
Returns The intrinsic toString method returns a string.
Implementation
override intrinsic function toString() : string
Private::toString();
Private function toString() : string {
if (qualifier === null)
return identifier;
return string(qualifier) + "::" + identifier;
Re: ES4 draft: Object
On Mon, Mar 10, 2008 at 11:11 PM, Jeff Dyer [EMAIL PROTECTED] wrote: it would be helpful to follow up with possible solutions or at least insight into what makes it abhorrent (your word). FWIW, I also did not grasp the force of the objection, and would like to understand better. No doubt the WG has attitude. There are strong personalities involved and we have had our share of knocks. Sometimes that shows. It can probably show less if everyone makes an effort. The WG has most of the implementors one could hope for, so this opportunity shouldn't be wasted. -- Robert Sayre I would have written a shorter letter, but I did not have the time. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Function
On 3/10/08, Lars Hansen [EMAIL PROTECTED] wrote: First draft of the spec for the Function class. Please comment. Suggestion: deprecate the Function constructor and static invoke(). Almost all of its uses are better handled by function expressions and, in those cases where eval() in required, one can use eval(). -Jon ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Function
On 3/10/08, Erik Arvidsson [EMAIL PROTECTED] wrote: There are valid use cases for new Function (...) and Function(...). One that comes to mind is getting an attribute in DOM and make it into an event handler. Yes, the Function constructor and meta::invoke can be replaced by eval but Function needs to be there for ES3 compatibility. ...which is why I wrote deprecate, rather than remove. In other words, I'm suggesting treating the Function constructor the way we're treating Function.arguments. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Insurrection (was: ES4 draft: Object)
On Mon, Mar 10, 2008 at 8:11 PM, Jeff Dyer [EMAIL PROTECTED] wrote: On 3/10/08 5:40 PM, Waldemar Horwat wrote: I'm dealing with a serious insurrection of folks who believe that the ES4 working group has a bad attitude, based on Brendan's public comments and responses to issues like this one. They're quite visible. No doubt the WG has attitude. There are strong personalities involved and we have had our share of knocks. Sometimes that shows. You of all people should understand why. But please do share more about the insurrection you are dealing with. Maybe then we can be more sensitive. I hope Waldemar is not counting me as a member of that insurrection. My problem with the ES4 proposal has nothing to do with the attitude and personality of the ES4 WG members. Quite the opposite. I have come to like and respect those of you I have come to know. Since Brendan is mentioned explicitly above, I'll mention the high regard I've come to have for Brendan in particular. I have also enjoyed every encounter I have had with the group as a whole. A vague disclaimer is nobody's friend. --Willow Rosenberg, Buffy episode: The Initiative True friends stab you in the front. --Oscar Wilde I do not wish to offend anyone. I know I am speaking harshly about work that many here have invested in heavily. But in the interests of clarity, I will speak plainly below. I hope the discussion will continue from here with its customary civility. I have serious problems with the proposed ES4 *design* -- to the point that I have a hard time taking it seriously. I hope and expect that it will be crushed by its own weight. I fear that it might become widely adopted, and we will instead be crushed by it. In any case, I have decided that my energies as a new EcmaScript committee member are better spent on the ES3.1 WG, as the other members of that WG seem similarly inclined to look for the *smallest* reasonable language that meets our goals http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_goals. The current fad in language design is expressive static type systems. As a result, several recent type systems have grown eat their language. Java 1.5 is a particularly nasty example. Simple bits of Java code become so overwhelmed by complex type declarations as to obscure the logic of the code itself. Proposed ES4 suffers from the same disease, though it has not (yet) come down with as bad a case as Java. I applaud Jeff's and Lars' recent document of proposed deferrals from proposed ES4. After reading this document carefully, I was then able to reread the proposed ES4 overview document and imagine the smaller language they are suggesting. This language I still believe to be too large, but at least it would now be small enough to be worth criticizing. ES3 has several abstraction mechanisms: * lambda abstraction, which it gets approximately as right as Scheme! * objects as a generalization of records, which has some pros and cons * prototype-based sharing of common behavior, which is used almost exclusively by JavaScript programmers to express only class-like patterns. Altogether, ES3 has many virtues and many problems. One of its great virtues is its almost perfect support for lexical nesting. Virtually any thisless construct that could appear at top level can also appear within a nested lexical context with the same meaning. ES3 also avoids the CommonLisp trap of multiple namespaces, instead siding with Scheme's single namespace approach. Even ignoring ES4's type system, ES4 adds all the following abstraction mechanisms to those in ES3: * classes * packages * units * namespaces I have not heard anyone explain any of these as syntactic sugar that could be expanded away into remaining language elements, so I fear all of these would be fundamental. Worse, several of these constructs can only appear at top level, and so destroy the almost perfect lexical nestability enjoyed by ES3. If instead classes, for example, were defined purely by syntactic expansion to the constructs in ES3.1, then classes would inherit the lexical nestability of the constructs they expand into. Even Java's classes are lexically nestable! The namespace mechanism seems motivated by a failure to appreciate the power available by modest extensions of simple lambda abstraction. ES3 already provides some of the features for supporting such modest extensions: Several libraries (such as YUI) already use naming paths such as foo.bar.baz. This is supported by ES3's lexical scoping combined with its extensible records and its property lookup notation. Why should we prefer foo::bar::baz? ES3 already suffers from having two bottom values -- null and undefined -- with no general consensus of when one should use which. How are we to regard mixed naming paths such as foo.bar::baz? When should one use a record as a naming container vs a namespace? What is gained by having two mechanisms? I could go on and on about ES4's types gone
Re: ES4 draft: Object
On Mon, 10 Mar 2008, Waldemar Horwat wrote: intrinsic function propertyIsEnumerable(name: EnumerableId, flag: (boolean|undefined) = undefined): boolean I too find the second parameter here abhorrent. Please find another way to solve it (Brendan's namespace idea maybe) or remove this feature altogether. I believe what Waldemar is saying is that the method has a name that implies that it is a getter, but that the proposal has it working as a setter. This has a number of disadvantages. Primarily, it is unintuitive for authors. This makes code maintenance significantly more complicated, as readers of code tend to assume that getters cannot have side effects. This leads directly to bugs. We should design ES4 in a way that someone who is experienced with other programming languages, but who has never learnt ES4, can by and large correctly guess what any arbitrary ES4 code is doing. In this particular case, we have failed to achieve that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
