ES4 stable draft: object initializers
Here is the third draft, which I have tentatively labeled as stable.
Please note the OPEN ISSUES, the input of everyone on these would be
appreciated.
--lars
Title: Object initializers
Object initializer syntax
NAME: "Object initializer syntax"
FILE: spec/language/object-literals.html
CATEGORY: Expressions (E262-3 chapter 11)
SOURCES:ES3; REFERENCES [1]-[7]
SPEC AUTHOR:Lars
DRAFT STATUS: DRAFT 3 - 2008-04-10
REVIEWED AGAINST ES3: YES
REVIEWED AGAINST ERRATA:YES
REVIEWED AGAINST BASE DOC: YES
REVIEWED AGAINST PROPOSALS: YES
REVIEWED AGAINST CODE: NO
REVIEWED AGAINST TICKETS: YES
IMPLEMENTATION STATUS: ?
TEST CASE STATUS: ?
OPEN ISSUES
(Note, in the absense of debate on the following issues the
resolution will invariably be to make no changes to the draft.)
* There is no way to control enumerability of a property without
giving it a non-public namespace or making it a fixture. One
possibility without adding yet another keyword is to signal
non-enumerability by the explicit use of the 'public' namespace:
{ public::x: 10 } /* not enumerable */
It's unambiguous but feels a little hackish, since the rule
for enumerability is that public properties are enumerable.
* There is no way to seal the object created by an object
initializer, as a prefix 'const' annotation only distributes
across the fields of the object and does not imply anything about
the object as a whole.
* The meta::prototype facility does not allow 'null' as a value.
Brendan thinks it's important that it should allow that in order
to allow objects to work as primitive (but reliable) maps; I'm not
sure what the impact will be. In particular, objects thus created
cease to behave like other objects in the system, as they will
have no (prototype) method suite. Of course, the intrinsic
methods will still be there. Discuss.
* It would be possible to replace 'meta::get()', 'meta::set()',
'meta::has()', 'meta::delete()', 'meta::invoke()', and
'meta::prototype()' with 'get*()', 'set*()', 'has*()',
'delete*()', 'invoke*()', and '__proto__', respectively. The
purpose would be to avoid having to worry about whether the
identifier 'meta' can be used as a syntax marker in the way it
currently is.
CHANGES SINCE DRAFT 2 (2008-04-07)
* Removed the copying of type information from initializing
expressions to fixtures in the case of 'const' and 'var' annotated
properties
* Made it possible to make a getter/setter pair into a fixture
by annotating the getter and setter with 'var'.
* Many(!) small wording changes and bug fixes (thanks to Brendan)
CHANGES SINCE DRAFT 1 (2008-03-20)
* Added optional 'const' and 'var' prefixes to the initializer to
imply 'const' or 'var' for all fields.
* Specified that a 'const' or 'var' prefix on a field records the
type of the value being stored in the type of the object, absent
any other annotation; the previous draft used '*' for the types.
* Specified that repeated field names are allowed only if the
initializer as a whole does not use any new ES4 features
* Introduced catch-all methods 'meta::get' and so on
* Introduced 'meta::prototype'
* Added the facility described in [6] for annotating the initializer
with a nominal class type.
* Added "Open issues" section; one more reference; wording changes.
REFERENCES
[1] ES4 base document
[2] Ticket #164
[3] Ticket #165
[4] Ticket #219
[5] Ticket #319
[6] Ticket #370
[7] Bug fixes proposal, item about comma at the end of the field list
[8] Compatibilities document
[9] Enumerability spec (forthcoming)
[10] Ticket to be filed: should allow :void on _expression_ closures
Synopsis
This draft spec tries to pin down everything that has been
proposed and tentatively agreed about object initializer syntax and
semantics. A brief rationale is attached at the end.
Primary syntax
In its general form an object initializer is comprised of an
optional keyword (const or var), followed by a brace-delimited
comma-separated list of fields with the last field optionally followed
by a comma, followed by an optional type annotation.
ObjInit ::= ["const" | "var"] "{" ( ( Field "," )* Field ","? )? "}" [ ":" Type ]
Field ::= FieldName ":" AssignmentExpression
| "var" FieldName ":" AssignmentExpression
| "const" FieldName ":" AssignmentExpression
| ["var"] "get" FieldName "(" ")" [":" Type] FunctionBody
| ["var"] "set" FieldName "(" Param ")" [ ":" "void" ] FunctionBody
| "meta" "::" "prototype" ":" AssignmentExpression
| "meta" "::" "get" "("
String functions
Hi all! I am new to this list and perhaps my questions have been answered. If so, could anyone point me to those discussions. I see that string.trim is part of the suggested spec. Coming from PHP the thing I miss the most when programming JavaScript is the plethora of string functions, and the printf family of functions. Besides trim, I have not been able to see any suggestions. My questions: What string functions have been discussed? Are there any more that might make it? If I provide my use case, might a new function be considered for inclusion? Have the printf/sprintf been considered for inclusion? If so, with named parameters as in Python (which I do miss in PHP)? The functions I personally miss the most are: - ucfirst - number_format - sha1 - levenshtein As well as ltrim and rtrim, but I see that they are being discussed on the wiki. Lars Gunther ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
RE: String functions
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keryx Web Sent: 10. april 2008 10:59 To: es4-discuss@mozilla.org Subject: String functions Hi all! I am new to this list and perhaps my questions have been answered. If so, could anyone point me to those discussions. I see that string.trim is part of the suggested spec. Coming from PHP the thing I miss the most when programming JavaScript is the plethora of string functions, and the printf family of functions. Besides trim, I have not been able to see any suggestions. There are no other accepted proposals for extending the set of string functions, apart from making some string methods also available as static methods on the string class (since they are generic anyhow). My questions: What string functions have been discussed? Are there any more that might make it? If I provide my use case, might a new function be considered for inclusion? Not likely at this date, but you can always try. Have the printf/sprintf been considered for inclusion? Similar functions have been considered, and rejected. Curiously, I can't find writeups of the rejected proposals now. (Don't know what you would do with printf() since there's no stdout.) If so, with named parameters as in Python (which I do miss in PHP)? The functions I personally miss the most are: - ucfirst - number_format - sha1 - levenshtein Presumably one of the formatting functions on Number will suit you for number_format; the others are probably out of the question. As well as ltrim and rtrim, but I see that they are being discussed on the wiki. But are not included in the spec. --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: String functions
On Thu, Apr 10, 2008 at 1:30 PM, Lars Hansen [EMAIL PROTECTED] wrote: Have the printf/sprintf been considered for inclusion? Similar functions have been considered, and rejected. Curiously, I can't find writeups of the rejected proposals now. Referred to in: https://mail.mozilla.org/pipermail/es4-discuss/2007-October/001307.html ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
ES4 draft: enumerability
Here's the first draft explaining how enumeration works in ES4.
--lars
Title: Enumeration
Enumerability
NAME: "Enumerability"
FILE: spec/language/enumerability.html
CATEGORY: Object model
SOURCES:?
SPEC AUTHOR:Lars
DRAFT STATUS: DRAFT 1 - 2008-04-10
REVIEWED AGAINST ES3: NO
REVIEWED AGAINST ERRATA:NO
REVIEWED AGAINST BASE DOC: NO
REVIEWED AGAINST PROPOSALS: NO
REVIEWED AGAINST CODE: NO
REVIEWED AGAINST TICKETS: NO
IMPLEMENTATION STATUS: ?
TEST CASE STATUS: ?
OPEN ISSUES
* The rationale for the decision not to enumerate fixture properties
is a bit feeble.
REFERENCES
[1] proposals:iterators_and_generators
[2] http:www.ecmascript.org/es4/spec/Object.html
[3] proposals:bug_fixes [FOR.IN.LOOP.CREATION.ORDER]
[4] ES3 spec 12.6.4
[5] proposals:bug_fixes [ITERATE.NULL.AND.UNDEFINED]
Synopsis
The purpose of the present spec is to define what it means for a
property of an object to be "enumerable", that is, what it means for
the property to be discovered when the properties of an object are
enumerated by for-in and for-each-in loops [4].
This spec also describes in high level terms the facilities that
are available to user programs to implement variations on enumeration.
Enumeration and itemization in ES4
According to [1], enumeration and itemization in ES4 is specified
in terms of the new iterator protocols using a system-defined helper
class called Enumerator. A section below contains a brief
description of how the translation is performed. The central point is
that enumeration is implemented by an Enumerator instance.
The constructor of
Enumerator optionally takes some namespace values:
iterator class Enumerator.T {
public function Enumerator(obj, f, deep, ...namespaces) {
...
}
public function next(): T {
...
}
}
An Enumerator created on an object obj will produce (from
its next method) a succession of the enumerable properties of
obj: those dynamic properties of obj whose "enumerable"
attribute [2] is set, filtered by the contents of namespaces. If
deep is true, then the objects in the prototype chain of obj
are included in the enumeration. Enumeration is always performed
starting at obj; properties are produced in the order they were
inserted into obj [3]; when the properties in obj are
exhausted the process is repeated on the immediate prototype of
obj, if any.
There is a distinct namespace in ES4 known as the "compatibility
namespace" or "no namespace". In code, this namespace is denoted by
the keyword public.
When an Enumerator is created with an empty set of namespaces,
it filters the enumerable attributes by the compatibility namespace,
and all property names produced are string values -- the property
name without the namespace, because the namespace is always the
compatibility namespace.
When an Enumerator is created with a nonempty set of
namespaces, it filters the enumerable attributes by those namespaces
only, and all property names produced are Name values: namespace
and name pairs.
(Punchline.) Normal enumeration and itemization by the
for-in and for-each-in loops result in the
creation of Enumerator instances with an empty sets of namespaces
and deep set to true. Ergo, normal enumeration behaves as in
ES3.
Programs that needs to enumerate properties in specific
namespaces, or that only need to perform shallow enumeration, can
create custom Enumerator classes. It is possible that ES4 ought
to provide utility functions to make this simple, but experimentation
will show.
Rationale and discussion
The rephrasing of enumeration in terms of iteration allows the
for-in and for-each-in statements to be used for
iteration, which is exceptionally handy.
Regarding namespace filtering and enumeration by default of only
public properties: Namespaces are used by user programs for privacy
and integrity. For example, the private attribute on properties
and methods of a class is just the name of a system-generated
namespace. It would be a breach of privacy for arbitrary code to be
able to enumerate arbitrary properties on an object, since the private
property names would be revealed in the form of Name objects, from
which the private namespace could be exposed. Yet it is useful for
code to enumerate properties in namespaces controlled by that code.
So the compromise -- which is also right for compatibility with ES3 --
is that only public properties are enumerated by default; all
system-provided namespaces can be obtained by naming them (a class
method can evaluate the _expression_ private to obtain the object
representing its private namespace); and custom Enumerator
instances can be constructed to enumerate names in
Re: Strict mode recap
On 4/10/08, Jon Zeppieri [EMAIL PROTECTED] wrote:
var o = { null var count = 100, ... };
Sorry: two syntactic mistakes, here, one of which is interesting.
The boring one is my use of '=' rather than ':'.
But after reading the object initializer draft, I see that, if the
intent of the above were legal, the syntax would be:
var o = { var null::count: 100 };
Is it still the case that instance variables in classes are defined like:
public var count = ...
If so, why the difference (discounting the colon/equal part, that is)?
-Jon
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
RE: Strict mode recap
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jon Zeppieri
Sent: 10. april 2008 21:31
To: Lars Hansen
Cc: liorean; es4-discuss@mozilla.org
Subject: Re: Strict mode recap
On 4/10/08, Jon Zeppieri [EMAIL PROTECTED] wrote:
var o = { null var count = 100, ... };
Sorry: two syntactic mistakes, here, one of which is interesting.
The boring one is my use of '=' rather than ':'.
But after reading the object initializer draft, I see that,
if the intent of the above were legal, the syntax would be:
var o = { var null::count: 100 };
I don't think null is a valid namespace (but I'm still waiting
for Jeff's spec on names to verify that) and it would in any
case be redundant; when we talked about it being legal, the
meaning was the compatibility namespace, which is what you
get by just leaving it off.
Apart from that there's no problem. var is used to indicate
a mutable fixture property, but it is just a flag (as is const).
The primary form is just { ns::id: val }, which is a
straightforward evolution of the ES3 form { ns: val }.
--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
