Re: ECMAScript Harmony
On Wed, Aug 13, 2008 at 2:26 PM, Brendan Eich [EMAIL PROTECTED] wrote: It's no secret that the JavaScript standards body, Ecma's Technical Committee 39, has been split for over a year, with some members favoring ES4, a major fourth edition to ECMA-262, and others advocating ES3.1 based on the existing ECMA-262 Edition 3 (ES3) specification. Now, I'm happy to report, the split is over. That is good to know. A split committee is good for no one and nothing, It led to contrasting ideas. There remain challenges, in particular getting off of the untestable and increasingly unwieldy ES1-3.x spec formalism. Unit tests: * help developer understanding * provide examples for discussion * provide conformance suite for implementors * define boundaries on what is and what is not supported* The tests could use a custom test runner or use an existing one. It would be useful if the testrunner could be run in a browser. It would be helpful to have code comments in the tests, indicating exactly which rules of the spec are being tested, so that the reader can quickly go to that section of the spec (spec in HTML). Real code examples in the spec would be useful, too. I can easily see a bookmarklet used to capture and execute the example selection of the spec. * defining not supported could be as simple as having an assertion test that should be ignored, and should be marked ignore, along with a comment as to why the test is ignored (use of Host object, et c). Ignored tests can be a useful form of documentation. As Waldemar Horwat (Google) said on the final day, the meeting was seminal, I like it. Garrett /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: How to escape implicit 'with (this)' of a method body
On Fri, Aug 1, 2008 at 1:03 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Jul 31, 2008, at 5:24 AM, Dave Herman wrote:
We should take this problem seriously. ...
Dynamic scope is very bad.
Specifically:
- Classes are supposed to provide integrity, but dynamic scope makes
the
internals of code brittle; any variable reference inside the
implementation could be subverted by the seemingly innocuous insertion
of a property.
- Dynamic dispatch has a reasonably understandable cost model, but
only
if it's confined to explicit property references. With dynamic scope,
any variable reference could potentially be very expensive.
- Generally, code within a `with' block is brittle and hard to
understand, and as Tucker says, the implicit `this.' means that all
code
inside class methods is within a `with' block... this means that all
code inside class methods is brittle!
- In the past, this has been enough for many programmers to deprecate
all use of `with' -- we should certainly hope to avoid the same
happening for classes.
I'm not sure of the benefits on the whole of implicit 'this' for class
methods, but isn't it plausible to apply it only to static properties
and not dynamically inserted ones,
What is dynamically inserted? I guess would mean properties added to
an instance of a non-sealed class.
so all references continue to be
bound at compile time and this sort of brittleness does not come up?
I think I remember discussion that 'this' in a static context was not valid.
If 'this' in a static context points to the class itself, it allows
for the possibility of the class having a static method, with a
private constructor and a public getInstance method with code
something like:
class E { static function f(){ return new this; } }
E.f()
[object E]
Works in the RI.
But I there was apparently a reason that that was not good, so that is a bug.
http://bugs.ecmascript.org/ticket/74
Garrett
Regards,
Maciej
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Fri, Jul 18, 2008 at 7:39 AM, Allen Wirfs-Brock [EMAIL PROTECTED] wrote: John, Thanks for pulling together all the various versions of Object.extend. Not all. It's useful to have them in one place. There are a couple of things you mentioned that I wanted to clarify. Neither Object.create nor Object.clone was not intended to be a directly replacement for Object.extend. I'm a little confused by the double negative here. Can you clarify? Allen, John, you two seem to be top-posting to significantly bad effect. Have either you considered replying inline-style? http://en.wikipedia.org/wiki/Posting_style#Inline_replying Garrett [snip] ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Fri, Jul 18, 2008 at 10:56 AM, John Resig [EMAIL PROTECTED] wrote: Not true. YAHOO.lang.extend uses prototypal inheritance. YAHOO.lang.extend is similar in name only - YAHOO.lang.augmentObject is the one that's actually similar to the functionality used by other code bases. You're prev response seems to have come from the discussion of Object.create. Object.create, with only one argument, is the same as beget. The beget function makes a new object that inherits members from an existing object. The rationale doc fails to make mention of this. Is YAHOO.lang.extend(Sub, Sup, extras) less similar in functionality to object.create(sub, super) than the other augmentation rountines? I think it's worth a look. s = new Sub; s - [[Prototype]] = Sub.prototype s - [Prototype]] [[Prototype]] Super.prototype Object.create from rationale doc Function 'getPropertyDescriptorObject' would be a fictitious method that is somehow able to get all of the properties in Sup.prototype (even the DontEnum ones), and convert that into an object that matches the propertyDescriptor here. Object.create(Sub.prototype, getPropertyDescriptorObject(Sup.prototype)); s = new Sub; s - [[Prototype]] = Sub.prototype s - [Prototype]] [[Prototype]] Super.prototype YAHOO.lang.extend seems more closely related to Object.create than any of all of the rest of the code you (John) posted up; particularly the real version of first one (jQuery):- http://jqueryjs.googlecode.com/svn/trunk/jquery/src/core.js Garrett --John ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Wed, Jul 16, 2008 at 5:50 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Jul 16, 2008, at 4:10 PM, Allen Wirfs-Brock wrote: [snip] 1) It seems like Object.clone as you have described it is not suitable for the mixin type use case where an object gets properties/methods from two others. Or at least, it only does half the job. It seems like Object.clone might create compatibility with existing code. There is already a widespread use of an Object.clone on the web. Has this been considered? Garrett Regards, Maciej ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Fri, Jul 18, 2008 at 12:40 PM, John Resig [EMAIL PROTECTED] wrote:
You're prev response seems to have come from the discussion of
Object.create.
No? We've been discussing the viability of a new Object.extend() method to be
introduced in ES3.1.
The title of the thread is object static methods rationale doc and
the first post has a link to the doc.
The first mention of I see of extend was by Brendan, who merely
asked: Did you consider prototype's Object.extend method.
To which Doug replied: Yes we did.
And Allen later replied: As far as I can recall, we didn't discuss a
specific formulation that corresponds to Object.extend
Mozilla has offered a proposal and is looking to implement it in SpiderMonkey.
I see a bug report for that mentioned in the thread.
Object.extend seems to be a misnomer for augmenting objects. It
might contrast with Prototype.js Object.extend. augment or mixin
or even flatten would do the trick.
/**
* Object.create
* @description Creates a new object based on \
* subject with propertyDescriptor as the [[Prototype]]
* @param subject
* @param {PropertyDescriptor} propertyDescriptor
* properties with attributes for A's prototype
*/
1) Object.create doesn't modify subject/receiver, extend does
2) Object.create takes objects, extend takes 2 functions + 1 object descriptor
The aforementioned Object.create and YAHOO.lang.extend are a completely
separate utilities which should be judged on their own merits.
And as I type this, I see now a new message from Allen: I thought
that we were generally discussing how Object.extent related to the
Object meta functions that are already in the 3.1 draft.
That is what I though, too.
Garrett
--John
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Fri, Jul 18, 2008 at 2:02 PM, Allen Wirfs-Brock
[EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:es4-discuss-
[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Friday, July 18, 2008 12:28 PM
...
You're prev response seems to have come from the discussion of
Object.create. Object.create, with only one argument, is the same as
beget. The beget function makes a new object that inherits members
from an existing object. The rationale doc fails to make mention of
this.
See the first complete paragraph on page 13
Note that Object.create without its optional second argument is
essentially the same operation as
the beget function that was been widely promoted. We (perhaps not
surprisingly) agree with the
utility of this function but felt that the word beget is probably
confusing to many non-native English
speakers.
Does object.create add an object to the first argument's prototype
chain? That's not explicitly stated, and one has to hunt down Doug's
begetObject. (below)
Does the propertyDescriptor describe an object added to the front of
the object's prototype chain?
=
Object.prototype.begetObject = function () {
function F() {}
F.prototype = this;
return new F();
};
Lasse Reichstein Nielsen's clone function, c. 2003:-
Object.prototype.clone = function () {
function myConstructor = function(){};
myConstructor.prototype = this;
return new myConstructor();
}
=
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/0c1cc7f1cb314f8e/5d06e72e55d5bf11?#5d06e72e55d5bf11
Garrett
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Thu, Jul 17, 2008 at 8:37 AM, John Resig [EMAIL PROTECTED] wrote: I wanted to bring up some further evidence for the widespread use of an extend() method. Here are the top 5 JavaScript libraries and their associated versions of Object.extend(): There are a couple points that are very important here: 1) They all extend the base object with the enumerable properties at least one other object. Not true. YAHOO.lang.extend uses prototypal inheritance. 2) There is very little done to prevent properties coming in from [SomeObject].prototype - this is mostly because libraries opt not to use .hasOwnProperty() in favor of speed and/or cross-browser compatibility (older versions of Safari and IE Mac don't have hasOwnProperty). Carelessness could be another reason. It is not hard to find bugs by looking at the latest version of YAHOO.lang.extend, for example. Garrett --John [snip top post] ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
On Wed, Jul 16, 2008 at 1:16 PM, Allen Wirfs-Brock [EMAIL PROTECTED] wrote: -Original Message- From: Brendan Eich [mailto:[EMAIL PROTECTED] Right now, the best I can come up with is that it should be a relatively efficient way to test for the existence of a possibly inherited property. The in operator tests for the existence of a possibly inherited property. var hasProp = (p in o); Garrett ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Object static methods rationale document
2008/7/15 Allen Wirfs-Brock [EMAIL PROTECTED]:
I've up loaded to the wiki a new document titled: Proposed ECMAScript
3.1
Static Object Functions: Use Cases and Rationale
A couple of questions for you:
My first question: How does an ES3.1 sealed object relate to fixtures?
__| ES 3.1 __| ES4___
Sealed object | Object.seal | fixture (var)
My second question is about Object.create. Object.create() mixes adding a
prototype to an object with a
specialized context where the (verbose) object literal contains certain
property names, such as value, take on contextual meaning to the
property.
1. What happens when an unrecognized property is in the descriptor? (1)
2. Is it only possible to define attributes on the top level? (2)
(1)
Object.create(myProto, {
method3: {
enumerable: false, writable: false,
novalue : true // no [[value]] + custom attribute
},
,method2: undefined
});
(2) Object.create(myProto, {
o1: {
enumerable: true, writable: false,
value : {
enumerable : false,
value : undefined
}
}
});
Garrett
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Newly revised Section 10 for ES3.1.
2008/7/9 Allen Wirfs-Brock [EMAIL PROTECTED]:
I've just finished reworking section 10 to better accommodate block scoped
function declarations and const statements. In the course of this I had to
make various decisions about the semantics. The primary purpose of this
message is to provide visibility to those decisions and to get feedback on
them.
In introducing const statements and block scoped function declaration I
tried to apply two over-riding principles:
1) Anything that is valid to do in ES3 continues to have the exact same
semantics.
2) Anything thing that is new (or non-standard) and would not be valid in
ES3 should have a semantics that is rational and consistent with a future
introduction of block scoped Let variable bindings
A FunctionDeclaration in a block is not valid in ES3, so apparently
that is the reason for your note.
Here are the results:
All var declarations continue to be hoisted to top-level execution
context. Vars never have block level scope or extent.
(top-level mean the global code, eval code, or the top-level of a
function.
This sentence is confusing. eval code is not necessarily global.
Reading further down, it seems that you mean to define top-level as
a new term for what we already know to mean [[Scope]] and then to
define a block scope term. It seems that you are aiming to
differentiate between function scope and a new type of block scope.
If my assumption is correct, then creating a new type of block scope
does not necessitate changing the term [[Scope]] to top level.
[[Scope]] can still be [[Scope]] and block scope can be called
whatever you like ([[Block]], [[BlockScope]], et c)
Does this sound reasonable?
Function declarations and const declarations are processed in parallel
within a lexical contour (top-level or block). Neither has precedence over
the other, unlike the manner in which function declarations take precedence
over formal parameters in ES3.
A top-level function declaration over-writes any like-named formal
parameters or preceding like-named function declarations. This is an ES3
semantics.
The global object cannot have parameters, so I should probably assume
that top-level means the same thing as [[Scope]] in ES3.
When you use a made-up word like over-writes it is unclear. It could
mean any of:
1) replaces the value
2) replaces the value and attributes
3) shadows a property in the scope chain (some do use the term
override in this way)
It is not clear what you mean.
Top-level function declarations are writable. Subsequent declarations or
assignments may change their value. This is an ES3 semantics.
I'm not sure how you understand it, but let me explain how I
understand it, and maybe you'll see why what you've written is
confusing to me.
A FunctionDeclaration creates a property on the Variable object (or
replaces the value and attributes if it it already exists).
To quote the relevant part of the spec:
| 10.1.3 Variable Instantiation
|
| Every execution context has associated with it a variable object.
| Variables and functions declared in the source text are added as
| properties of the variable object. For function code, parameters
| are added as properties of the variable object.
http://bclary.com/2004/11/07/#a-10.1.3
[snip]
Within in a block, function declarations are read-only bindings. Since
declarations in blocks are new, this is a new semantics.
IOW, a FunctionDeclaration creates a property of the BlockScope with
the attributes {ReadOnly, DontDelete}
In the course of this, I noticed a number of conditions that plausibly might
be restricted in the cautious subset, but currently aren't specified as
such:
·Illegal for a function to have duplicately named formal parameters
Is this a problem in ES3?
·Illegal for a function to contain a top level function declaration
with a function name that is the same as a formal parameter.
·Illegal to have multiple top level function declarations for the
same function name
·Illegal to have a function declaration with the same name as var
declaration.
·Illegal for a function to contain a var declaration with the same
name as a formal parameter.
·Illegal to assign to a top-level function name.
Five sensible suggestions, but they would be incompatible with ES3.0
(see quote above).
[snip]
10.1.6.1Usage Subset cautious Restrictions
For functions defined within an execution subset restricted to the cautious
subset, the activation object is only initialized with an arguments
property if the function mentions arguments freely in its body. In which
case the arguments property is initialized with attributes {[[Writable]]:
false, [[Enumerable]]: false, [[Flexible]]: false}.
That would be incompatible with ES3. Arguments is not ReadOnly (or
Writable:false). (Doesn't seem like it would create a problem but
this violate your rule 1)
Valid ES3:
function z() {
arguments =
Fwd: Side-effects of some Array methods ...
Back to list -
On Fri, Jun 27, 2008 at 1:27 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Jun 27, 2008, at 6:51 AM, Pratap Lakshman (VJ#SDK) wrote:
The side effect is as follows: if this does not have a length
property, it ends up getting one; if this does have a length
property, but is not an Array, that length property will get
updated.
True, and not just for pop -- for all generic Array methods that
mutate length.
What is the rationale for this?
I don't recall a detailed rationale on this point, but the pseudo-
code is simplest without a special case that avoids creating a
'length' property if one does not exist, and it's easy to rationalize
caveat hacker -- if you wrote Array.prototype.pop.call(p), you
wanted to have effects on your pizza ;-). The simpler specs are a
good thing.
Trying to change this now seems dicey. We don't know if any web
scripts count on this edge case. Creating length may be a requirement
because lazy pizza coders left 'length' out, knowing it would be
created, and then depended on it becoming 0 (e.g., in a expression
-- if undefined it would become NaN and the condition would be false).
There does not seem to be any profit in taking risk by changing the
semantics.
A program that called pop() on an object w/no length would know right
away if it failed.
Silent failure would also occur with a length property that has the
attribute ReadOnly. For example, a String (or Function) object, or a
Host object, such as a NodeList (reasonable use case).
javascript:var p = new String(two);
void(Array.prototype.pop.call(p)); alert(p.length);
javascript:var p = document.childNodes; alert(p.length);
try{void(Array.prototype.pop.call(p)); alert(p.length);} catch(ex)
{alert(ex.name); }
FF: alert 2, then TypeError
IE: alert 2, then, Choke on ex.name.
SF: alert 2 twice, No error
Op: alert 1, then Error
Should the req be that - length - property be defined on the object
itself (not prototype)? If not, [[Put]] will create it if it doesn't
already exist. Should the - length - property be checked for either
of:
1) the absence of ReadOnly attribute, or
2) being a property that has a setter
If no check is made, or if a check is made - either way, an error will
occur. The difference is where.
speculation
ISTM that if IE is going to support generics on Host objects, and
going along with that hypothetical scenario and further pretending
that Array generics would actually work with Host objects and not be
buggy, then, in that case, the Array generics would probably see more
widespread use.
/speculation
Now, in the hypothetical scenario, would some built-in algorithmic
safety checks help fail faster? Checks for 1) hasOwnProperty and not
readonly or 2) has a setter
Garrett
/be
___
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
Fwd: Side-effects of some Array methods ...
to list -
On Fri, Jun 27, 2008 at 3:04 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Jun 27, 2008, at 2:07 PM, Garrett Smith wrote:
A program that called pop() on an object w/no length would know right
away if it failed.
Why do you say that?
I worded that very poorly. It was in response to:-
There does not seem to be any profit in taking risk by changing the semantics.
- I should have written: The algorithm could be changed such that
program that called pop() on an object w/no length would know right
away.
js function pizza(){}
js pizza.prototype.pop = Array.prototype.pop
function pop() {
[native code]
}
js p =new pizza
[object Object]
js p.length
js p.pop()
js p.length
0
js a = []
js a.pop()
js
Now, in the hypothetical scenario, would some built-in algorithmic
safety checks help fail faster? Checks for 1) hasOwnProperty and not
readonly or 2) has a setter
Again, we don't know what failing faster (you mean throwing a new error as
an exception) would break. The shell session above shows how fail-soft could
leave scripts executing and even behaving well. Throwing an exception that's
not caught would rain on such scripts' parades.
I hardly call that a parade. It looks like a toy program aimed at
doing nothing useful. If your argument is addressing an object which
does not have an own property - length -, then what about calling -
pop - on an object that
a) has a getter and no setter for - length
b) has a - length - property with the attribute ReadOnly (the NodeList example).
How do you address these concern? Is it better to fail fast or fail
later? If later, and in the case or attempting to set a ReadOnly
property, then should the failure be silent? (String example). What
about the NodeList example?
BTW, I am keeping this on ES4 list. IMO, having fewer lists keeps
things simpler (fewer language versions would also seem to be
simpler).
Garrett
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Side-effects of some Array methods ...
On Fri, Jun 27, 2008 at 3:57 PM, Brendan Eich [EMAIL PROTECTED] wrote: On Jun 27, 2008, at 3:45 PM, Garrett Smith wrote: to list - I am not the one replying to sender only -- all of my replies to you have cc'ed the list. I know. I had a mistake and hit 'Reply'. Then, realizing that, I put the message back on the list. You have replied twice to me only, then resent as reply-alls. What mailer are you using? Sorry, it was an accident. I meant to put it on the list and hit 'Reply'. I would not mind if you mail me personally. I just had a mistake. I'm using GMail. I need a web based mailer because I use multiple machines and usually mobile. I'm open to suggestions for a better mailer or alternative to gmail. [snip] My shell example is not the parades plural referenced above, merely a demo of fail-soft behavior. The unknown web scripts that might depend on that behavior could be doing useful work based on the current semantics (having parades). Your point seemed clear (at least to me). I know the idiom rain on their parade. It is possible that someone expects that behavior , and in fact, that behavior is guaranteed by the current spec. How do you address these concern? Is it better to fail fast or fail later? If later, and in the case or attempting to set a ReadOnly property, then should the failure be silent? (String example). What about the NodeList example? This is not a green-field design exercise. My point is that browsers do what ES1-3 said (depending on the Array method; generics were there all along, but some were added IIRC after ES1). Code tends to depend on detailed semantics (not always, but more often than you'd think). Why rock the boat? I'm just trying to figure out what the best way to handle error condition. It's somewhat related to what Pratap brought up: | The side effect is as follows: | if this does not have a length property, it ends up getting one; | if this does have a length property, but is not an Array, that | length property will get updated. | What is the rationale for this? Leads to thinking about API design. I guess it's not bad the way it is. Anyone calling pop() on a NodeList can get what should be expected. OTOH, maybe it's worth considering if a better alternative exists. What is a green-field design exercise? Garrett /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
2008/6/24 Allen Wirfs-Brock [EMAIL PROTECTED]:
Assuming the string index semantics I defined in my previous message, what
should the effect of setting a numeric property on a string whose property
name is a valid character position into the string?
For example:
var s = new String(abc)
s[1]; /* not valid in ES3, should yield b under extended semantics*/
s[1] = x; /* valid in ES3, but has nothing to do with the string
value */
s[1];/* both in ES3 and with extended semantics would yield x
Should the assignment, s[1] = x, still be valid in the present if we
support string indexing?
Argument for allowing: It's backwards compatible. There may be existing
ES3 programs that depend upon it.
Argument for disallowing: Allowing characters of a string to be accessed
using property access syntax makes the string elements appear as if they are
actually properties. There appears to be a joining of s[1] and
s.charAt[1}.
Since the value of a string is immutable, any property that is joined to a
an element of a string value should be a read-only property.
My inclination would be to disallow, but preserving existing code is one of
our top priorities. What do the existing implementation that support indexed
access to string elements do? If some of them disallow defining such
properties then there is probably enough existing divergence that the
compatibility issue doesn't really apply.
Webkit seems to have implemented a specialized [[Put]] for strings.
When the property is numeric, the property setting fails silently.
This can be observed by an example:-
javascript:(function(){var a = new String(Alan); a[0] = E;
alert(a[0]); })();
FF2: E
Sf3: A
OP9: E
IE7: E
It seems to me that Webkit's behavior is a bug.
This is something that I blogged about last year.
http://dhtmlkitchen.com/?category=/JavaScript/date=2007/10/21/entry=Iteration-Enumeration-Primitives-and-Objects#magic-string-source
Second issue:
I defined string index property access in such a way that such properties
appear to be non-enumerable. Is this reasonable? It's inconsistent with
arrays. However, saying that they are enumerable implies that for-in should
iterate over string element indexes which it now doesn't do. Also what
about meta operations like Object.prototype.hasOwnProperty? My current
semantics would cause it report true for string element indexes. Is this
reasonable? It's another set of incompatibilities.
It seems that nobody should be using a for in loop on a String or SV.
String.prototype.trim = ...
Would be an obvious reason. Using hasOwnProperty might be a
consideration, but why would anyone want to?
Garrett
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: More string indexing semantics issues
On Wed, Jun 25, 2008 at 1:49 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Jun 25, 2008, at 1:33 PM, Garrett Smith wrote:
On Wed, Jun 25, 2008 at 1:25 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Jun 24, 2008, at 11:45 PM, Garrett Smith wrote:
(putting this back on the list; it contains nothing personal).
None of this explains why you think the WebKit behavior is a bug.
It seems like a bug because it prevents property assignment to String
objects. I also said something along the lines of: I'm not overly
concerned with that.
You seem
to be hung up on specialized [[Put]] but I don't understand what that has
to do with anything.
I was trying to answer the OP (Allen's) question: Should the
assignment, s[1] = x, still be valid in the present if we support
string indexing? Which is a natural way of asking about [[Put]]/
[[CanPut]].
ISTM the heart of the problem is to allow special [[Get]] access to
characters in the String; that the problem itself has nothing to do
with [[Put]]. However, Allen asked a question with real world
implementation. Webkit's behavior, to me, appeared to have implemented
a modified [[Put]]. I'm trying to understand what Webkit does and it
seems related to the Allen's question:
Should the assignment, s[1] = x, still be valid in the present if
we support string indexing?
Where what webkit does has different results of what mozilla and Opera do.
In spec terms, WebKit's behavior can be explained in
terms of strings having additional DontDelete ReadOnly properties.
Let me get this straight:
Webkit's behavior can be explained in terms of String objects having
additional properties with numeric names and the attributes
{DontDelete ReadOnly}
Is that what you meant?
The
Mozilla behavior can be explained as strings having those same additional
properties, but they are not ReadOnly. In both cases, index properties past
the last character do not exist ahead of time.
My observations indicate otherwise. Webkit does not appear to create
additional properties to String objects.
javascript:alert(Object(foo).hasOwnProperty(0));
FF2 - true
Sf3 - false
Op9 - false
Where does the 0 property exist, Maciej? Is this bug related to
hasOwnProperty?
It appears to me that Mozilla and Opera and Webkit all implement a
specialized [[Get]], where Opera and Mozilla do:
1) Look for property P on String object.
2) Look for String instance charAt( P )
3) Look in String prototype.
Webkit does:-
1) Look for String instance charAt( P )
2) Call the[[Get]] method on S with argument P.
javascript:var f = Object(1234567);void(String.prototype[0] = 0);
void(f[0] = 8); alert(f[0]);
8 in Opera9 and FF2.
0 in Saf3.
In Opera, the object doesn't have numeric properties, and only appears
to have special [[Get]]:-
javascript:alert(0 in Object(foo));
javascript:alert(Object(foo)[0]);
Op9 - false and f
FF2 - true and f
Mozilla has the properties on the object and Opera doesn't.
(this explains why - Object(foo).hasOwnProperty(0) - is false in Opera.
The reason for the way WebKit does things, for what it's worth, is because
index properties of the string are checked first before normal properties
(because they can't be overwritten), so abc[1] can be as fast as an array
access instead of going at the speed of normal property access.
So the [[Put]] method on a String instance is different in Webkit.
Garrett
Regards,
Maciej
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Fwd: ES3.1 Draft: Array generics
Hello Pratap, Were you genuinely interested in feedback? Is Function described by Type in ES3.1? Are top-level generics part of the spec (Array.forEach)? You or one of your colleagues signed me up for the ES3.1 list, then, apparently, after I replied directly to you, decided to ignore the reply and unsubscribed me from the list. I can't be bothered to resubscribe myself. Posted to ES4 discuss. Garrett -- Forwarded message -- From: [EMAIL PROTECTED] Date: Sat, May 31, 2008 at 6:27 PM Subject: Fwd: ES3.1 Draft: Array generics To: [EMAIL PROTECTED] Messages from non-subscribers are automatically rejected. Please subscribe to the list first before attempting to post, or ensure that you are posting using the address you subscribed with. -- Forwarded message -- From: Garrett Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED], es4-discuss@mozilla.org es4-discuss@mozilla.org Date: Sat, 31 May 2008 18:27:10 -0700 Subject: Fwd: ES3.1 Draft: Array generics fwd to list. On Sat, May 31, 2008 at 1:44 AM, Garrett Smith [EMAIL PROTECTED] wrote: 2008/5/19 Pratap Lakshman (VJ#SDK) [EMAIL PROTECTED]: It would be sufficient and more correct to say: throw a TypeError rather than throw a TypeError exception So it should probably read one of:- 1) If callbackfn does not implement [[Call]], throw a TypeError. 2) If callbackfn is not a function, throw a TypeError There is also an absence of top-level generics:- Array.forEach - This avoids having to write:- [].forEach.call( nodeList, fun ); Note on host objects: Whether the forEach function can be applied successfully to a host object is implementation -dependent. - support Array Generics for host object, for example, a DOM NodeList in abstract view. [].sort.call( ul.getElementsByTagName(li), byName ); Garrett Regards, Garrett pratap ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Draft: Array generics
On Sun, Jun 8, 2008 at 2:50 PM, Pratap Lakshman (VJ#SDK) [EMAIL PROTECTED] wrote: Garrett, I apologize. I was not ignoring you. Yes, I am interested in feedback! The initial Array generics proposal did not include the thisObj param as it was felt that it could open the door to some security issues. We were even contemplating cutting Array generics from ES3.1 altogether. Later, based on feedback from many of us on the discuss lists, we are going back to specifying the Array Generics to include the thisObj param; these generics will be available on Array.prototype. I am currently revising the proposal, and it will include the following: Array.prototype.indexOf Array.prototype.lastIndexOf Array.prototype.every Array.prototype.some Array.prototype.forEach Array.prototype.map Array.prototype.filter and also, Array.prototype.reduce Array.prototype.reduceRight I meant the top-level generics: Array.forEach(arrayLike, fn); It was not my argument for: Array.prototype.forEach(fn[, thisArg]); The thisArg was what Erik had brought up. The other question was regarding the: If Type(callbackfn) is not a function, throw a TypeError exception. ES 3.0 doesn't define Function as a Type. In fact, the spec often uses: If x is a Function. There is: if Type(x) is Number, but not if Type(x) is Function. That is why I asked if ES 3.1 defines Function for Type(). Does it? ES 3.1: Type, section 8 http://bclary.com/2004/11/07/#a-8 If ES 3.0 had forEach, it would probably have read something along the lines of one of: 1) If callbackfn does not implement [[Call]], throw a TypeError. 2) If callbackfn is not a function, throw a TypeError. I am not sure how you got unsubscribed; there must be some mistake! I don't know either. Garrett pratap [snip] ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Draft: Array generics
On Sun, Jun 8, 2008 at 2:50 PM, Pratap Lakshman (VJ#SDK) [EMAIL PROTECTED] wrote: Garrett, I apologize. I was not ignoring you. Yes, I am interested in feedback! OK, but you seem to have misunderstood me. The initial Array generics proposal did not include the thisObj param as it was felt that it could open the door to some security issues. We were even contemplating cutting Array generics from ES3.1 altogether. Later, based on feedback from many of us on the discuss lists, we are going back to specifying the Array Generics to include the thisObj param; these generics will be available on Array.prototype. I am currently revising the proposal, and it will include the following: Array.prototype.indexOf Array.prototype.lastIndexOf Array.prototype.every Array.prototype.some Array.prototype.forEach Array.prototype.map Array.prototype.filter and also, Array.prototype.reduce Array.prototype.reduceRight I meant the top-level generics: Array.forEach(arrayLike, fn); It was not my argument for: Array.prototype.forEach(fn[, thisArg]); The thisArg was what Erik had brought up. The other question was regarding the: If Type(callbackfn) is not a function, throw a TypeError exception. ES 3.0 doesn't define Function as a Type. In fact, the spec often uses: If x is a Function. There is: if Type(x) is Number, but not if Type(x) is Function. That is why I asked if ES 3.1 defines Function for Type(). Does it? ES 3.1: Type, section 8 http://bclary.com/2004/11/07/#a-8 If ES 3.0 had forEach, it would probably have read something along the lines of one of: 1) If callbackfn does not implement [[Call]], throw a TypeError. 2) If callbackfn is not a function, throw a TypeError. I am not sure how you got unsubscribed; there must be some mistake! I don't know either. Is there a link to get back on? Garrett pratap [snip] ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3.1 Draft: Array generics
2008/5/19 Pratap Lakshman (VJ#SDK) [EMAIL PROTECTED]: I have uploaded to the wiki a draft proposal (link) for Array generics. I have extracted the Array portion of the ES3 spec, added a rationale (with hyperlinks) at the beginning, and made relevant changes to the included section 15.4 text, with some comments added. I have tried to be mindful of compat. If Type(callbackfn) is not a function, throw a TypeError exception. There is no function Type defined in ES 3.1. Are you incorporating the ES4 Type, or does callbackfn must implement [[Call]]? It would be sufficient and more correct to say: throw a TypeError rather than throw a TypeError exception As with my comment for ES4, there are many benefits to having the spec in HTML. It is easy to link directly to a fragment, it doesn't take a plugin, I don't get prompted to update Acrobat Reader, HTML is not slow to load as launching Reader is. But most of all, it is easier for the rest of the world to link to and discuss (if that is desirable to the committee) Regards, Garrett pratap ___ 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
Fwd: ES3.1 Draft: Array generics
fwd to list. On Sat, May 31, 2008 at 1:44 AM, Garrett Smith [EMAIL PROTECTED] wrote: 2008/5/19 Pratap Lakshman (VJ#SDK) [EMAIL PROTECTED]: It would be sufficient and more correct to say: throw a TypeError rather than throw a TypeError exception So it should probably read one of:- 1) If callbackfn does not implement [[Call]], throw a TypeError. 2) If callbackfn is not a function, throw a TypeError There is also an absence of top-level generics:- Array.forEach - This avoids having to write:- [].forEach.call( nodeList, fun ); Note on host objects: Whether the forEach function can be applied successfully to a host object is implementation -dependent. - support Array Generics for host object, for example, a DOM NodeList in abstract view. [].sort.call( ul.getElementsByTagName(li), byName ); Garrett Regards, Garrett pratap ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
That sore thumb propertyIsEnumerable.
propertyIsEnumerable, as a setter, sets the DontEnum flag for the
object's own property. A value of 'false' makes the prop not show up
in - for in.
propertyIsEnumerable, as a getter, gets the value of the negation of
the DontEnum flag, and does not check the prototype chain. Has nothing
to do with whether or not the object shows up in - for in.
The addition adds a non-orthogonal aspect, apparently to add some
needed functionality.
This unituitive behavior is especially problematic to amateur, or
unskilled developers. The following code example from google
demonstrates this to be true:
http://doctype.googlecode.com/svn/trunk/goog/base.js
if (Object.prototype.propertyIsEnumerable) {
/**
* Safe way to test whether a property is enumarable. It allows testing
* for enumarable on objects where 'propertyIsEnumerable' is overridden or
* does not exist (like DOM nodes in IE).
* @param {Object} object The object to test if the property is enumerable.
* @param {string} propName The property name to check for.
* @return {boolean} True if the property is enumarable.
* @private
*/
goog.propertyIsEnumerable_ = function(object, propName) {
return Object.prototype.propertyIsEnumerable.call(object, propName);
};
} else {
/**
* Safe way to test whether a property is enumarable. It allows testing
* for enumarable on objects where 'propertyIsEnumerable' is overridden or
* does not exist (like DOM nodes in IE).
* @param {Object} object The object to test if the property is enumerable.
* @param {string} propName The property name to check for.
* @return {boolean} True if the property is enumarable.
* @private
*/
goog.propertyIsEnumerable_ = function(object, propName) {
// KJS in Safari 2 is not ECMAScript compatible and lacks crucial methods
// such as propertyIsEnumerable. We therefore use a workaround.
// Does anyone know a more efficient work around?
/ BROKEN: this approach checks the prototype chain with - if(propName in object)
// (gsmith)
if (propName in object) {
for (var key in object) {
if (key == propName) {
return true;
}
}
}
return false;
};
}
Because we can see that the author appears to have made the assumption
that propertyIsEnumerable would check the prototype chain. This is a
perfectly natural assumption.
What is more confusing is that with the new proposal:
function X(){}
X.prototype = { p : true; };
var x = new x;
x.propertyIsEnumerable('p'); // false, p is in the [[Prototype]]
for(var prop in x)
alert(prop); // alerts 'p'
Garrett
2008/3/17 Lars Hansen [EMAIL PROTECTED]:
Draft 3 of the spec for the Object class. Changelog near the beginning.
(Notably this version includes draft code for __createProperty__.)
--lars
___
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: Date Format?
On Tue, Apr 1, 2008 at 1:36 AM, Robert Sayre [EMAIL PROTECTED] wrote:
2008/3/31 Nathan de Vries [EMAIL PROTECTED]:
Without being part of a standard such as ES4...
It is a library problem. The ES4 language spec is not the place to fix
every standard library deficiency.
That's funny. Even if it's missing the point.
One benefit of having a standard formatter would be expected standard
result. I've seen quite a few date formatters that assume the whole
world speaks English. Korea likes having their dates formatted in
Korean. Similarly for Japanese, and Spanish.
Keeping property-objects of key-value pairs for each language seems to
be considerably large overhead.
Here's English:-
months : {
full : [January, February, March, April, May,
June, July, August
, September, October, November, December],
abbr : [Jan, Feb, Mar, Apr, May, Jun,
Jul, Aug, Sep, Oct, Nov, Dec]
},
One strategy is to (1) make a file for each locale.
CalendarLocale_en.js. This can be seen in the DynArch DHTML Calendar.
This is more efficient than (2) cramming every locale in one file.
leaving non-localized strings in the main file is never a good option.
Either way, it requires translating date components manually, for each
language. I don't speak Korean, and if nobody in my company does, then
what, hire a translator?
The other approach (and a fairly common one), is (3) to assume that
English is the only language. This fails to fulfill the use case of
localized date formatting.
Properly formatting dates, solution (1), in ES is a lot of work.
Is there a way to add Date Formatting to ES4 without adding too much
bloat to the language? What's the least ES4 could do? How much would
that cost, in terms of bloat to the language?
What I'm not getting from this group is the answer to solve the
problem of formatting dates. Lets not turn a blind eye to the problem.
Garrett
--
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
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: assert expression
Sometimes errors might happen outside of an assert. Then the developer would have to try to rely on other things, like Spidermonkey's error.lineNumber and error.stack, or even window.onerror, even though it is buggy. It would be useful to get more error detail for free (w/o having to predefine an assert()). Is it a security problem to have a lineNumber and/or stack by default on Error? If so, could it be addressed in some other way? I don't have any problems with assert(), however, I would probably use it mostly during debugging, to try and track down an error. In this way, adding assert() would be a replacement for inserting console.log(). I would not put in too many assert()'s in by default because testing should be thorough and it should be done in another layer. I would still want to know about other runtime exceptions that weren't wrapped in assert(). As for removing assertions, I would do that in my build process, if I needed to. Garrett On Wed, Apr 16, 2008 at 10:08 AM, David Flanagan [EMAIL PROTECTED] wrote: David Flanagan wrote: [snip[ David ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Class method addition and replacement (was Re: AOP Compatibility)
On Thu, Apr 3, 2008 at 5:20 PM, Peter Hall [EMAIL PROTECTED] wrote:
If you want mutability, you can define methods as vars in the first place.
class Foo {
// can be modified on a per-instance basis
public var f : function (a:T):S = function (a:T):S {
return null;
}
}
A common idiom is to have a default value in the ADT's prototype. (I'm
calling a constructor-with-a-prototype an ADT -- ES3, which doesn't
have true class classes).
ES3 example:
function Button() { }
Button.prototype = {
ondepress : function(){},
_isDepressed : false
};
var b = new Button;
b.ondepress = buttonDepressed;
- b - just got a new instance property: ondepress.
So when defining an ES4 class, instead of putting a default -
ondepress - in the prototype, a dummy function will be added to the
instance.
I'm not understanding the syntax well enough to post an example.
This will have the result of more function objects being created for a
program that does not use - ondepress - for Button instances. Would
the Button class be better off by having a private EMPTY function? Or
maybe that goes on a larger scale, to the event notification system,
but then that wouldn't work unless the event system's empty Function
instance was immutable.
[snip]
___
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: Date Format?
2008/3/31 Nathan de Vries [EMAIL PROTECTED]: On Tue, 2008-04-01 at 00:39 +0200, Igor Bukanov wrote: Date.prototype.toLocaleFormat(format) in SpiderMonkey provides access exactly to strftime functionality. As with prior discussion regarding PTC, being in SpiderMonkey is relatively useless to those of us programming for the web. Firefox uses SpiderMonkey. Cheers, -- Nathan de Vries ___ 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: complexity tax
On Wed, Mar 26, 2008 at 8:23 AM, Douglas Crockford [EMAIL PROTECTED] wrote: Brendan Eich wrote: And over-minimizing a language imposes a complexity tax on programmers using it. That is true. To decide whether to evolve JS or shrink it, you need only look at two things: 1) problems JS hackers run into every day, which are not solved by more idiomatic functional programming hacks that add cycle and space bloat to their libraries and applications; 2) competition from other languages in runtimes vying to displace the browser. I think this is the specific point of disagreement. Complexity in a language does not necessarily reduce the complexity of programs. Not necessarily, but to be specific, simply adding 'private' access modifier would avoid a closure. This is good because its a lot more convenient and a lot clearer. I think the opposite may be truer. The difficulties we have had in the development community since 1999 were not due to over-minimization. They were due to features that did not work as expected or reliably over the various brands and versions. That is true. Implementation differences are significant difficulties. Other difficulties had to do with browser differences/competing technology platforms (layer, document.all). There are also limitations to the language itself that cause problems (no access modifiers, limited typechecking, enumeration). I disagree that limitations in the language did not cause difficulties. I think the opposite is true. I think that developers ran into problems when trying to add to Object.prototype. I think developers have struggled trying to figure out if [some_object] was a function or array. I think that developers exploited closures for all that closures had to offer. Closures are the most useful thing we have because there simply aren't other alternatives available. Garrett ___ 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: the global object
There are some global functions that I think should be deprecated and moved to a relevant class. encodeURIComponent et al have nothing to do with the Global object. Same with isNaN, isFinite. These should be deprecated and moved to the appropriate object. In the case of encodeURIComponent, that would be a URI object, and ideally one that would encapsulate useful behavior (not a mishmash of static methods, e.g. Math). Garrett 2008/3/12 Lars Hansen [EMAIL PROTECTED]: Enclosing Draft 1 of the global object spec. Quite a few changes here from ES3, and I've included a large expository section on eval that may not be appropriate for the final spec but which is probably useful right now, since it's the first attempt at a unified spec for all the eval changes that have been proposed. Probably a few rough edges here, but more than enough to start looking at. --lars ___ 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: the global object
On Tue, Mar 25, 2008 at 7:50 AM, Erik Arvidsson [EMAIL PROTECTED] wrote: Deprecation does not really buy you anything. Most people will never know something is deprecated and even if they do, they will most likely continue to use it. (Take escape and unescape as example.) No, actually, if you deprecate something, and provide a better alternative, you can remove the deprecated thing later. Take Object.prototype.eval, for example. Nobody uses that much anymore. If it's removed from Mozilla, probably some pages will break, but not that many. Most people know better than to use that. I'm surprised it's been hanging around in for so long. Garrett sniip On Tue, Mar 25, 2008 at 07:12, Garrett Smith [EMAIL PROTECTED] wrote: snip -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: the global object
On Tue, Mar 25, 2008 at 8:13 AM, Erik Arvidsson [EMAIL PROTECTED] wrote: Take Object.prototype.eval, for example. Nobody uses that much anymore. If it's removed from Mozilla, probably some pages will break, but not that many. Most people know better than to use that. I'm surprised it's been hanging around in for so long. Most people don't know about Object.prototype.eval and it was only available in Spidermonkey. That is why no one relied on it. It is true that that is an old feature and one that didn't catch on as much as escape/unescape. IT did get a fair amount of use c1999, where scripts would have code for IE using document.all and netscape using document.eval. Nobody does that anymore. It is evidence of a feature that was deprecated and has now been removed in Firefox 3. WRT escape, that has seen much less use lately. All the libraries are using encodeURIComponent and they don't even have a fallback for escape(). In fact, I don't see escape as being a property of the global object in ES4. Is it in the draft? Garrett -- erik ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Fwd: Array Generics and null
-- Forwarded message -- From: Garrett Smith [EMAIL PROTECTED] Date: Mon, Mar 24, 2008 at 11:27 AM Subject: Re: Array Generics and null To: Dean Edwards [EMAIL PROTECTED] On Mon, Mar 24, 2008 at 10:31 AM, Dean Edwards [EMAIL PROTECTED] wrote: Mike Shaver wrote: On Sun, Mar 23, 2008 at 2:44 AM, Dean Edwards [EMAIL PROTECTED] wrote: It seems we have three choices for Array.forEach(null) 1) Do nothing 2) Throw an exception 3) Use the current object and iterate that I prefer the first one, throwing an exception is acceptable too but the last one is counter-intuitive IMO. (2) Throw an exception. When? Checked or unchecked? -dean ___ 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
Fwd: Array Generics and null
I suspected that. It is the problem with Google Mail, which exhibited
a bug in Firefox.
Use case:
0) hit reply
1) click 'send'
2) hit 'stop'
3) click 'reply to all' and watch the To: field change.
4) watch Gmail send a mail *instantly*. Gmail displays headers in the
'show details' for all recipients (the same ones that appeared in the
To field).
Gmail does eventually update the incorrect headers; that last mail now
says it went only to 'Dean Edwards'.
The fix for this would require subscription-based Async's and locking.
Just another distraction from my message.
Garrett
On Sun, Mar 23, 2008 at 12:06 AM, Dean Edwards [EMAIL PROTECTED] wrote:
I assume you didn't intend to send this just to me.
I do that a lot too - click reply instead of replay all. :-)
-dean
Garrett Smith wrote:
Is there typed null?
If so, then typed null could typecheck for Array-like-ness.
Anything that is not Array-like or invalid could throw an error. Such
values would include:
null
undefined
any non-dynamic object that does not have a numeric length property
Ideally this would happen at compile time.
Garrett
On Sat, Mar 22, 2008 at 11:44 PM, Dean Edwards [EMAIL PROTECTED] wrote:
Mike Shaver wrote:
Dean Edwards wrote:
Array.prototype.forEach = function(block, context) {
Array.forEach(this, block, context);
}
I don't see how that helps, unless you expect A.p.g.c(null, f) to
differ from A.g(null, f) -- the former will need to make a |this|
from null, giving the window object in browser embeddings. I don't
believe that they should so differ -- do you?
I'd prefer Array.forEach(null) to do nothing, just like for (var i in
null) does nothing. I'm prepared to be convinced otherwise. :-)
-dean
___
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: Array Generics and null
On Sat, Mar 22, 2008 at 9:01 AM, John Resig [EMAIL PROTECTED] wrote:
Hello all -
It seems like there could be a couple solutions:
Objects that are not capable of running in an Array-generic should not
be attempted to run.
Would it make sense to use - like - for all the Array generics? Is
there an Iterable interface?
Array generic methods will be safer if they check their args and throw
an error - InvalidArgumentError, TypeError, UnlikeError - (whatever).
Invalid: (this will crash Firefox with endless loop):-
Array.forEach( { length : -1, 0: 12 }, iter );
function iter(a) {
console.log( a );
}
Garrett
--John
___
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: Error classes
On Tue, Mar 18, 2008 at 12:05 PM, Lars Hansen [EMAIL PROTECTED] wrote: -Original Message- From: Garrett Smith [mailto:[EMAIL PROTECTED] Sent: 18. mars 2008 11:57 To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft: Error classes On Mon, Mar 17, 2008 at 12:11 PM, Lars Hansen [EMAIL PROTECTED] wrote: (Didn't know who to follow up to so lamely following up to myself.) What does this have to do with getting a stack trace? I see. var color = el.style.color where el is null, a ReferenceError would be thrown. It would be useful to have a backwards-compatible way to get that stack trace. How can - assert - be detected? What about libraries that already have an assert() function? assertin window? Garrett --lars ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Function
Hi Dustin,
Well it does, apparently it was called the splat operator, which (to
me) sounds a better than spread. I think it works like:-
var args = [12, true];
new C(...args);
function C( count, isSemiAnnual) {
}
- Maybe one of guys writing the specs can comment on that.
It can be hacked in ES3:-
/**
* @param {Function} fun constructor to be invoked.
* @param {Array} args arguments to pass to the constructor.
* Instantiates a constructor and uses apply().
*/
newApply : function(fun, args) {
if(arguments.length === 0) return;
var f = arguments.callee, i;
f.prototype = fun.prototype;// Copy prototype.
f.prototype.constructor = fun;
i = new f;
fun.apply(i, args); // Apply the original constructor.
return i;
},
- from http://dhtmlkitchen.com/ape/build/APE.js
Garrett
On Thu, Mar 13, 2008 at 10:48 AM, Dominic Cooney
[EMAIL PROTECTED] wrote:
Why doesn't Function have something like apply that does the same as
in a new expression, i.e. allocate-init-and-apply? To put it another
way: given arguments in an array, I want to write:
F.thisThing(args) and have it mean the same as new F(args[0], args[1],
... args[n-1])
Or is what happens behind the veil of object creation detailed enough
that I can write a facsimile of it with apply? I guess something like:
var x = {};
x.prototype = F.prototype;
x = F.apply(x, args) || x;
But why force me to guess? No doubt I am wrong.
Dominic
On Mon, Mar 10, 2008 at 7:38 PM, Jon Zeppieri [EMAIL PROTECTED] wrote:
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
___
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
Date Format?
Will ES4 have a simple date formatter? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Greedy triple-quoted string literals
On Feb 19, 2008 10:21 AM, liorean [EMAIL PROTECTED] wrote: On Feb 18, 2008 1:17 PM, liorean [EMAIL PROTECTED] wrote: On 19/02/2008, Garrett Smith [EMAIL PROTECTED] wrote (o.f)(); // =o This should be window. No it shouldn't. The grouping syntax specifically doesn't call GetValue in order to make delete and typeof operators able to use function-call-like syntax. Which makes up for this asymmetry. Right. Thank you. -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Function inside if statement?
if(a) {
function b(){ }
}
A block can contain statements. A statement can't start with the
function keyword.
Mozilla's Core JavaScript guide explains that of |b| should be
evaluated as a functionExpression, but this isn't right.
Source:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Functions#Conditionally_defining_a_function
What should the above code do?
Should it be:
if(a) {
(function b(){ });
}
SHould it be a function declaration, just like a variable statement?
if(a) {
var b;
}
Spidermonkey treats |b| as a function declaration as a statement (example).
No imlementations I know throw a SyntaxError; instead, the behavior is
implementation-specific.
Garrett
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Exception handling vs. hasNext()
Which is better?
var nodes : int;
var widgetMap = Widget.instances; // a map.
var it:Iteratorstring = widgetMap.getKeys();
-- this: --
try {
widgetMap.get(it.next()).hide();
}
catch(Exception e) {
if(e instanceof StopIteration) {
}
}
-- or this: --
while(it.hasNext()) {
widgetMap.get(it.next()).hide();;
}
It might be the case that there might be some error
I want to catch other than StopIteration. In that case, to be
backwards-compatible and work across implementations, the developer
must use conditional
checks inside 1 catch block.
A hasNext() would not prevent the developer from writing such code.
Omitting hasNext() forces developers to use exception handling for
non-exceptional condition.
How does using try/catch for normal termination of the loop look?
It looks like all exceptions are unchecked in ES4. correct? (I cannot
verify this to be true because
I am unable to access the spec namespace on ecmascript.org.)
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Exception handling vs. hasNext()
Hi Erik,
Can you explain a little better by showing a code example?
Thanks.
On Nov 16, 2007 5:44 PM, Erik Arvidsson [EMAIL PROTECTED] wrote:
One benefit of StopIteration is that code inside map/some/every etc
can just throw a StopIteration to stop the iteration. The same thing
is harder to keep clean with a hasNext/next pattern.
On Nov 16, 2007 5:30 PM, Garrett Smith [EMAIL PROTECTED] wrote:
Which is better?
var nodes : int;
var widgetMap = Widget.instances; // a map.
var it:Iteratorstring = widgetMap.getKeys();
-- this: --
try {
widgetMap.get(it.next()).hide();
}
catch(Exception e) {
if(e instanceof StopIteration) {
}
}
-- or this: --
while(it.hasNext()) {
widgetMap.get(it.next()).hide();;
}
It might be the case that there might be some error
I want to catch other than StopIteration. In that case, to be
backwards-compatible and work across implementations, the developer
must use conditional
checks inside 1 catch block.
A hasNext() would not prevent the developer from writing such code.
Omitting hasNext() forces developers to use exception handling for
non-exceptional condition.
How does using try/catch for normal termination of the loop look?
It looks like all exceptions are unchecked in ES4. correct? (I cannot
verify this to be true because
I am unable to access the spec namespace on ecmascript.org.)
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
--
erik
--
Programming is a collaborative art.
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3 quasi incompatibilities
Function findDuplicate is more like mark duplicates. The side effect
is that it adds a __marker property to each object. As it stands, this
function can not be called more than once. The second call might be
passed a different array, but containing one of those objects that had
the __marker left over. Calling delete in a second loop would make the
algorithm 2n (best time). But this is not entirely safe; calling
delete on a Host object or window property will throw errors in
JScript env; and the property will still be there. So you can set
__marker = false, but then you've got a 2N algorithm that leaks a
__marker to objects in the program.
Unsafe:
if (map[array[i]])
// array[i].toString() returns a property name that exists in the
prototype chain of map (such as toString).
Safer:
if(map.hasOwnProperty([array[i]])
However, relying on toString in the second part is still unsafe.
findDuplicate([1, 1, !window, false, new Date()+'', new Date()+'']);
What is really going into this Array?
I think I see the intent, but the function is easily breakable, even
if fixed to have a second loop to set marker to null when done; and
including the hasOwnProperty fix.
Interop might be an issue, but the code is broken even in ES3.
JavaScript does not provide basic functionality for unique collections.
Consider a case where we have an array-like collection of objects and
we want to exclude duplicates. Not uncommon at all.
This could be a shopping cart of unique items (properties), a list of
attendees, a ledger of customers, a merge of n number of Lists,
containing top-scoring players
We want a unique collection.
Using SortedSet:
//---
// lis1, lis2 and lis3 are NodeList of LI, in Abstract View.
function compareFn(a, b) {
return getScore(a) - getScore(b);
}
var players:Set = new SortedSet( compareFn );
players.addAll(lis1);
players.addAll(lis2);
players.addAll(lis3);
var top10:Set = new Set(players);
top10.trimToSize(10);
//---
Pros: fast, explicit
What's missing from ES4:
Set, SortedSet
Using Array:
//---
// Copy of array-like, as array, w/o duplicates.
var players = Array.concat(lis1, lis2).concat(lis3).unique();
players.sort(compareFn);
var top10 = players.toArray();
top10.length = 10;
//---
Pros: compact
Cons:
1) probably not as efficient (using quicksort)
2) slightly less explicit than the SortedSet example
What's missing from ES4:
Array.prototype.unique();
Array.prototype.toArray( arrayLike ) (also as Array.toArray(arrayLike))
ES3 concat and splice are the only way to obtain a copy of an array.
These are not explicit uses, but workarounds for a missing arraycopy
function.
I don't know how this problem could be solved with a Map. Doesn't feel
natural here. Here's my best shot at it:
//--
var players = new MapObject,Object();
// Add all the players from each list into the players Map.
for(var i = 0; i lis1.length; i++) {
if(!Map.containsKey(lis1[i])
players.add(lis1[i], null);
}
for(var i = 0; i lis2.length; i++) {
if(!Map.containsKey(lis2[i])
players.add(lis2[i], null);
}
for(var i = 0; i lis3.length; i++) {
if(!Map.containsKey(lis3[i])
players.add(lis3[i], null);
}
var keys = map.getKeys();
var newPlayers = Array.toArray(keys);
newPlayers.sort(compareFn);
newPlayers.length = 10;
//--
Pros:
Cons:
1) not very straightforward or intuitive; not explicit
2) Verbose, requires two collections and a for loop.
3) Not efficient
What's missing:
Array.toArray( arraylike );
On Nov 9, 2007 10:00 AM, Lars Hansen [EMAIL PROTECTED] wrote:
Map and intrinsic::hashcode are your friends, indeed. Cleaner solution,
too.
rambling
For non-dynamic classes you can still use meta::set and meta::get to allow
for
limited applications like this. I keep thinking that there are use cases
for
global meta::get and meta::set functions, so just like operator overloading
can be done by extending global, generic functions a la intrinsic::+, it
ought to
be possible to hook into catchalls on the global level, using generic
functions.
class C { ... } // not dynamic
meta generic function get(c: C, name) {
if (name == __marker)
...
else
return nextMethod()
}
meta generic function set(c: C, name, val) {
if (name == __marker)
...
else
nextMethod()
}
/rambling
--lars
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kris Zyp
Sent: 9. november 2007 09:20
To: es4-discuss@mozilla.org
Subject: ES3 quasi incompatibilities
or whether ES4 precludes the use of current ES3 AOP patterns and how
that might be solved. Among other things.)
ES3 AOP is in a
InterType Declarations, Cross-Cutting - how to in ES4?
InterType Declarations
InterType Declarations are a useful Iand popular) way of adding
functionality to an object, usually to the prototype of a constructor.
Lets say I have a class Widget that I want to borrow from:
class Widget {
private function Widget(){}
static {
getByNode : function():Widget { }
}
prototype {
var isBeingDragged : false,
valueOf : function(){ },
toString : function():String { },
}
function moveTo(x, y){ }
}
Class Orangutan {} // Borrows from Widget
In ES3, I can use a crossCut function:
crossCut : function(receiver, supplier, propsArray, borrowFilter) { }
What is the ES4 way to introspect or modify or a class?
I want to provide beforeAdvice to the static Widget.getInstance.
For other Orangutan, I want to provide afterAdvice to the constructor
(add to pool) (or is this aroundAdvice?).
I want to borrow the prototype properties of Widget, to Orangutan (for
default read access)
I want to borrow the static methods.
Is this done through the traits?
Can I modify a sealed class? My understanding is that a sealed class'
instances can't have dynamic props. what about the class itself?
Also, is there a way to get the function name from an anonymous
function via the identifier it's bound with, or do I have to type:
getByNode: function getByNode():Widget{ }. I find the repetition
annoying to my hands and eyes. I want access to the function name
without having to do this.
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: ES3 quasi incompatibilities
On Nov 11, 2007 7:18 PM, Yuh-Ruey Chen [EMAIL PROTECTED] wrote:
Garrett Smith wrote:
JavaScript does not provide basic functionality for unique collections.
It's trivial to implement an efficient Set class even in ES3 (with
certain restrictions on the type of the key) - just use objects which
are pretty much specialized hash tables (maps from string to values,
keys collides with prototype keys). For ES4, we have maps which are hash
tables as bareboned as you'll get in the language. I'm not sure why you
have all those |!Map.containsKey(lisx[i])| checks in your Map example,
since they're totally unnecessary.
Where is the string value in something like:
{a:1}
I wrote an Array-backed sorted set before but ended up not using it. I
did not like all the runtime checks and found another way to do what I
wanted to do.
A SortedSet is a bit trickier, because that would require some sort of
binary search tree to be efficient. But it can be done.
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
.newApply() ?
I know it's too late for a proposal, but I keep wanting a couple of
things for AOP stuff.
One is a newApply
Creational = {
getByNode : function(el){
if(!this.hasOwnProperty(instances)) this.instances = {};
return this.instances.hasOwnProperty(el.id) this.instances[el.id] ||
(this.instances[el.id] = this.new.apply(arguments)); // -- Fictitious
syntax.
}
}
function Widget(el, dir){
}
Wiget.getByNode = Creational.getByNode; // Borrow the getByNode method
So that way, I can have a Widget based on a node, yet still pass
varargs to the constructor.
Garrett
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Chris Wilson: What I think about ES4
On 11/4/07, liorean [EMAIL PROTECTED] wrote: On 04/11/2007, Mitch Skinner [EMAIL PROTECTED] wrote: Nicolas Cannasse wrote: Just curious, but am I the only one having trouble posting replies to Chris' blog? I posted a response to his response and answered his question that he asked me; absolutely nothing inflammatory or even rude in my post. Just trying to figure out if it's just me. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Chris Wilson: What I think about ES4
On 11/4/07, liorean [EMAIL PROTECTED] wrote: On 04/11/2007, Mitch Skinner [EMAIL PROTECTED] wrote: Nicolas Cannasse wrote: Just curious, but am I the only one having trouble posting replies to Chris' blog? I posted a response to his response and answered his question that he asked me; absolutely nothing inflammatory or even rude in my post. Just trying to figure out if it's just me. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Chris Wilson: What I think about ES4
On 11/3/07, Nicolas Cannasse [EMAIL PROTECTED] wrote: After the heated debate, I took time to write my opinion on the subject, for what it's worth : Debate? Where? I didn't see any debate on Chris' blog. It looked more like something we could expect to see from American politicians; or a good episode of Jerry Springer. Some vague claims, some suggestions, some accusations, but no debate. I want to see facts, cold, reasoned analysis, pros/cons. Real debate. And I want to see it here; debate on ES4 belongs here, on this list, not scattered through various blogs. Chris, where are you? Garrett Nicolas ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Object.prototype.clone
cloneObject( this ); // Error if this is window.
// enumeration is partially broken in IE, this loop will sometimes fail
for( var property in srcObj )
On 10/22/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have clone objects like this:
//
function cloneObject( srcObj ) {
if( srcObj == null ) { return srcObj; } //undefined or null
var newObject;
switch( typeof(srcObj) ) {
case object:
newObject = new srcObj.constructor();
for( var property in srcObj ) {
//Do not clone inherited values
if( srcObj.hasOwnProperty(property) || typeof( srcObj[property] ) ===
'object' ) {
newObject[property]= cloneObject( srcObj[property] );
}
}
break;
default:
newObject = srcObj;
break;
}
return newObject;
}
- Original Message -
From: Peter Michaux [EMAIL PROTECTED]
To: es4-discuss@mozilla.org
Sent: Monday, October 22, 2007 5:07 AM
Subject: Object.prototype.clone
Hi,
Is there a plan for a clone function in ES4?
Object.prototype.clone = function() {
function F() {}
F.prototype = o;
return new F();
};
The earliest reference I have found to this function is a post by
Lasse Reichstein Nielsen in 2003 on comp.lang.javascript
http://groups.google.com/group/comp.lang.javascript/msg/5d06e72e55d5bf11
In the past year this function has been evangelized by Douglas Crockford.
http://javascript.crockford.com/prototypal.html
Given the idea has persisted for at least a four year period as
something useful in a prototype-based language, would a clone function
be a good addition to the language itself?
Peter
___
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
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Object.prototype.clone
On 10/21/07, Peter Michaux [EMAIL PROTECTED] wrote:
Hi,
Is there a plan for a clone function in ES4?
Object.prototype.clone = function() {
function F() {}
F.prototype = o;
return new F();
};
The earliest reference I have found to this function is a post by
Lasse Reichstein Nielsen in 2003 on comp.lang.javascript
http://groups.google.com/group/comp.lang.javascript/msg/5d06e72e55d5bf11
In the past year this function has been evangelized by Douglas Crockford.
I had the misfortune of working on code that uses this pattern while
at Yahoo. Since Yahoo pretty much shuns testing and my boss didn't
really like me refactoring code, my debugging skills improved. What
mess of code. I still remember the code object. 1100+ line module
pattern
YAHOO.mst.app.code = (function(){
// 1100+ lines...
return {
};
})_
The guys would sometimes get confused and reassign the namespace to a
variable, too.
YAHOO.namespace(mst.app.code);
YAHOO.mst.app.code.getGlobal = function(k){};
YAHOO.mst.app.code = (function(){ // uh-oh, what happened to getGlobal?
});
An interesting device, hard to debug, confuses less-skilled
programmers, usually relies on too much anon functions/constructors.
Increases scope chain.
http://javascript.crockford.com/prototypal.html
I don't see the part about clone. Cloning brings up the issue of how deep.
Given the idea has persisted for at least a four year period as
something useful in a prototype-based language, would a clone function
be a good addition to the language itself?
A Clonable interface would be an OK addition. But cloning is tricky
when it comes to mutable objects
a = {
items : [1,2,3]
};
b = clone( a );
b.items.reverse();
a.items[0]; // 1 or 3?
How deep should clone go?
Peter
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: is ES4 getting too bloated?
(fwd to list - I clicked the wrong button again...)
On 10/21/07, Brendan Eich [EMAIL PROTECTED] wrote:
I know of two industry-scale implementations under way, in addition
to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all
implementing ES4 in the next six to nine months. There's no reason,
zero, apart from will to do something else, why Microsoft (which has
enormous resources, in expert people and money) couldn't do likewise.
Perhaps they yet will -- we don't really know what's coming in IE8 yet.
Give the overview at http://www.ecmascript.org/es4/spec/overview.pdf
a read and let us know what you think.
RegExp objects can be called as functions (equivalent to invoking
their exec method)...
Example:
/foo/('foo')
What is the purpose? To save five characters? e,g, .exec
I don't see how it fulfills a use case. It would seem to make code
more hot-doggable, and potentially confusing (less explicit)
function bork( a ) {
if( a( foo ) ) {
}
}
Doesn't it look like a is a function? Well, maybe in ES4, it's a RegExp.
If I were the code reviewer on that, I would ask the person to use
.exec. Why? Because it's confusing. Not everyone will expect that.
Come refactoring time, the next guy who looks at the code will have to
familiarize himself right away. He might not be a JavaScript expert
whose keen on the latest features. Maybe he's a Backend guy.
Contrast to that:
function mork( a ) {
if( a.exec( foo ) ) { // Ah, a looks like a RegExp.
}
}
How is this feature, callable regexps, justified? Why not just let
programmers use .exec?
I say:
It's not necessary, it makes the code less explicit. YAGNI!
Garrett
/be
--
Programming is a collaborative art.
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Object.prototype.clone
On 10/21/07, Kris Zyp [EMAIL PROTECTED] wrote:
http://javascript.crockford.com/prototypal.html
It is the act of creating a object that inherits from/delegates to the
provided object. Peter is suggesting sugar for one of the important
mechanisms in a prototypal language. I believe the copy semantic is used
in Self. clone is bit misleading (well, I think copy is too). With
classes, we call it subclassing. We could call it subobject :). Douglas
calls it begetObjet (nice), I personally think it is very valuable
construct and I like what it encourages, but on the otherhand it is so
easy/compact to create (about 4 lines of code), and it doesn't seem to be
the direction ES4 is headed, so it's omission seems reasonable.
function beget(o) {
function F() {}
F.prototype = o;
return new F();
}
var x = {
items : [1,2,3]
};
var y = beget(x);
y.items.reverse(); // reverse my y items.
x.items[0]; // What is it?
The point I made earlier about mutable objects addresses this very issue.
It's attractive, but easily breakable.
YAHOO.mst.app.code = (function(){
// 1100+ lines...
I don't think this doesn't have anything to do with the topic.
It's little off-topic. It can cause problems in real-world programming
was the point I was trying to make. Looking at Doug's side made me
remember that code and the (long, excruciating) time I spent, often @
the office until 8 or 10 on a Friday. I'm getting off topic again...
Garrett
Kris
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Type Checking?
Incomplete sentence Microsoft often says that it is necessary to retain backwards compatibility. I would hope they would [not continue on this path.] -- EDIT. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Type Checking?
On 10/11/07, Brendan Eich [EMAIL PROTECTED] wrote: On Oct 11, 2007, at 8:02 PM, Garrett Smith wrote: If you want to apply or call a non-function callable, use Function.apply(callable, thisp, argArray) or Function.call(callable, thisp, arg1, ...argN). So these are equivalent? aNonFunctionCallableObj() Function.call( aNonFunctionCallableObj ) We don't need to go back and forth -- I wrote essentially the same thing, but included the optional arguments. The two expressions you wrote are equivalent assuming the global object should bind to |this| for both to be equivalent. If an object is invokable with arguments (), but not a Callable, it's impossible to type check. IE's call-like operation on with () is not [[call]]. Why do you say that? There's no reflection of [[Call]] into the language yet, so how can you tell? Well yeah, you're right, I don't know, it's just a lame guess. Some evidence: * The caller does not provide a reference to the object it acts on. * The typeof operator. typeof appendChild == object; // true. I don't know what it is. (Don't rely on typeof x == function meaning x.[[Call]] exists -- browsers do not follow ES3 here, although we tried in SpiderMonkey for years before throwing in the towel.) Microsoft often says that it is necessary to retain backwards compatibility. I would hope they would You're barking up the wrong tree here. This is es4-discuss. Ok. I meant to say hope they would not continue with this (or something like that). Host objects that can act like functions but not be functions are confusing. So that that's out of scope for ES4; it's OK for host objects to have custom behavior. Mozilla has this weird function-like thing, too, (only with document.all, which is not used much anymore) As I keep saying, any reflection of document.all in an ES4 DOM level 0 plus IE quirks binding should indeed make (document.all is Callable) = true. I don't know what BackCompat mode means, but we do reflect document.all if a script uses it without object-detecting it, and only in such cases (since many well-written scripts fork based on if (document.all) ... else ... tests and we want to run the else clause). document.compatMode CSS1Compat -- standards mode BackCompat - quirks mode BackCompat supports document.all No, you're mixing things up. As I wrote, our document.all emulation has nothing to do with DOM specs or document.compatMode, and it works irrespective of the latter's value. quirksmode -- document.all works strict mode -- no document.all It is detectable. all in document Mozilla really made document.all look like IE's weird collection-that-can-be-invoked-with-(). Like, yeah -- that was the point! Was heavily debated and implemented. Water under the bridge, right? Garrett /be -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Type Checking?
Typechecking is a problem. typeof is limited and allows host objects to return anything. The problem is that some host objects return function, for example, a NodeList in Safari. This is perfectly legal, according to the spec. Checking instanceof between frames doesn't work. var i = document.getElementsByTagName(iframe)[0].contentWindow; i.someFunction instanceof Function; // false. How is type checking addressed in ES4? Garrett -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Type Checking?
On 10/10/07, Brendan Eich [EMAIL PROTECTED] wrote: On Oct 10, 2007, at 3:53 PM, Garrett Smith wrote: Typechecking is a problem. typeof is limited and allows host objects to return anything. The problem is that some host objects return function, for example, a NodeList in Safari. This is perfectly legal, according to the spec. See http://bugs.ecmascript.org/ticket/153 -- for a general, universal is-it-callable test, you would write if (it is Callable) ... How is type checking addressed in ES4? The |is| operator tests universal or Platonic type, which involves shared, immutable type descriptors that do not vary across windows or frames. So if (a is Array) ... will work no matter where a was constructed. Immutable type descriptor. I like it! /be -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: New Feature to JS 1.7
On 9/24/07, Brendan Eich [EMAIL PROTECTED] wrote: On Sep 24, 2007, at 10:51 AM, Garrett Smith wrote: http://wiki.ecmascript.org/doku.php?id=proposals:maintenance_of_es3 The docs for ES3 are gonna be updated? No commitment from the group yet to do this. Including some changes to the spec? Again no commitment yet from TG1 to pursue this. I personally believe that the unsound, untestable/non-executable ES3 spec is a rathole we should avoid. The errata (which are not complete by a long shot) that we have hosted at http://www.mozilla.org/js/ language/E262-3-errata.html would have to be incorporated, again with high risk of bugs and no way to test. I think we are much better off working on the ES4 refimpl and the spec derived in part from it. That is disappointing to hear. I sent an email to [EMAIL PROTECTED], as it is listed on the front of the manual, but did not get a reply. If the documentation were amended, understanding would most likely improve. BTW, I'm having trouble viewing ecmascript.org now. Garrett /be -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: New Feature to JS 1.7
On 10/8/07, Brendan Eich [EMAIL PROTECTED] wrote: On Oct 7, 2007, at 11:41 PM, Garrett Smith wrote: I personally believe that the unsound, untestable/non-executable ES3 spec is a rathole we should avoid. The errata (which are not complete by a long shot) that we have hosted at http://www.mozilla.org/js/ language/E262-3-errata.html would have to be incorporated, again with high risk of bugs and no way to test. I think we are much better off working on the ES4 refimpl and the spec derived in part from it. That is disappointing to hear. Why? Which particular word in unsound, untestable and rathole was wrong, so that you'd be disappointed we didn't charge down that tunnel? I sent an email to [EMAIL PROTECTED], as it is listed on the front of the manual, but did not get a reply. That mail made it to my attention. The problem besides the lack of soundness and testability is that editing minor corrections can be done, but creates a difference between the Ecma spec and the ISO version of it. Editing non-trivial fixes is not well-supported by Ecma process or JTC-1 Fast-track to ISO. The fix is to do a new Edition, but that's not going to happen just to fix a few (or even a lot of) errata. It has been over eight years since Edition 3, and the JS authors deserve better than a typo fix or three. True. Our work on Edition 4 is all but specified. Meaning, we're about ten months from really all but done with the spec -- spec- writing is hard work, but at least this time there will be a testable reference implementation provided along with the spec, and bug-fixed over time. Modern standards are not holy writ, and as you note not bug-free. They should move toward continual refinement and release, as software has (Windows Update, Apple Software Update, etc.). That is why IE is so far behind -- they dump a browser every 3 years, then process bug rept's for the next 2 years, gathering information for the next iteration. It's also why the other browsers are advancing faster. Shorter release cycles, public bug tracking, and Software update. The Ecma process is not nearly that continual. The Scheme community wants to move toward a more frequent update of their spec (R6RS, R6.1RS, etc.). I'm working with Ecma folks to explore a way forward along those lines, but it won't happen quickly. The best plan now is to get back to an every-two-years release footing, based on ES4. Shorter release cycles help to continually improve quality. If the documentation were amended, understanding would most likely improve. Maybe, but there're lots of JS books on shelves and people cope without delving into the corners of the spec that contain errata. We get very few complaints -- yours is one of a few cases where someone bothered to mail Ecma. But it's not just books! Browser QA should be able to ascertain if the implementation is correct of not. But since ES4 covers ES3, the manual will, too, and will correct problems in ES3. BTW, I'm having trouble viewing ecmascript.org now. Works for me at the moment. It looks like the problems of the ES3 spec are being positively addressed. Shorter release cycles and tests. One more thing that would help immensely: Interlinked HTML Format for the official release. Garrett /be -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: isPropertyEnumerable is going to stay broken?
On 9/10/07, Brendan Eich [EMAIL PROTECTED] wrote: On Sep 10, 2007, at 2:21 PM, Garrett Smith wrote: The fact that the method was called propertyIsEnumerable instead of isPropertyEnumerable is not great, but the way propertyIsEnumerable is designed is confusing to developers. I've never heard that complaint directly, or in a bugzilla.mozilla.org report. Can you cite complaints anywhere on the web? I believe you, but it would be good to have evidence. Web search: http://livedocs.adobe.com/flashlite/2/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Partsfile=0728.html http://www.adobe.com/livedocs/flash/8/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Partsfile=2578.html Apparently flash actually has a custom isPropertyEnumerable method. It's on Adobe's website. I don't do Flash, so I can't say much about it. It looks like a straight rename method, though. This guy wants a rename, too: http://lists.macosforge.org/pipermail/webkit-reviews/2005-December/002269.html isPropertyEnumerable and/or propertyIsEnumerable could return true if an object can be enumerated in a for-in loop, and check the prototype chain. Given the above change, the old (current) behavior could be achieved with: r.propertyIsEnumerable( p ) r.hasOwnProperty( p ); The change would allow for 4 different possibilities of r[ p ] Garrett /be -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)
On 9/22/07, liorean [EMAIL PROTECTED] wrote:
On 22/09/2007, Garrett Smith [EMAIL PROTECTED] wrote:
What I've found is that it's always giving wrong constructor property
with inheritance chains.
A -- B -- C
c = (new C).constructor;// A
snip I meant an enumerable superclass property!
You get that if you do the following:
function A(){}
function B(){}
B.prototype=new A;
function C(){}
C.prototype=new B;
Because if you do that, you replace the prototype containing the
original constructor property (e.g. a reference back to the function
C) with an instance of another constructor (e.g. B), but that instance
doesn't have the constructor property that the original prototype had.
If you want to keep the constructor properties, you need to do that
manually. (With the obvious result that then the constructor property
will be enumerable. Which can be changed through adding a call on
propertyIsEnumerable in ES4.)
Ah, sorry, I said a few things wrong!
1. constructor is DontEnum.13.2 - http://bclary.com/2004/11/07/#a-13.2
(It's the user-defined superclass property that is enumerable.)
1. The constructor property should be on the object instance *created*
by the function.
snip
How about a constructor property on the function instance?
2. (new function(){}).constructor should be Function.
But you understood what I meant even though I said it wrong. I meant
to say that the object instance's constructor property should be the
Function that new was called on.
Which could be done, of course, it should be a simple thing to add
that in the algorithm for [[Construct]]. But then we have the question
of what to do with constructors that return other objects than that
set up by steps 1 through 5 of the [[Construct]] algorithm. A
constructor can return other objects, you know.
snip
In ES4, it is a syntax error to specify a result type of a
constructor. If someone is using new F, the constructor property of
the instance should be F.
(new F).constructor; // should be F.
The constructor property should match the [[Construct]] property. This
should happen right before the prototype. Here's 13.2.2 with my edits:
13.2.2 [[Construct]]
When the [[Construct]] property for a Function object F is called,
the following steps are taken:
1. Create a new native ECMAScript object.
2. Set the [[Class]] property of Result(1) to Object.
-- ∆ set the [[Class]] of o to reflect the name F --
3. Get the value of the prototype property of F.
-- Set the constructor property of Result(1) to F --
4. If Result(3) is an object, set the [[Prototype]] property of
Result(1) to Result(3).
5. If Result(3) is not an object, set the [[Prototype]] property
of Result(1) to the original Object prototype object as described in
15.2.3.1.
6. Invoke the [[Call]] property of F, providing Result(1) as the
this value and providing the argument list passed into [[Construct]]
as the argument values.
7. If Type(Result(6)) is Object then return Result(6).
8. Return Result(1).
∆ Note: Although allowed in ES3, Functions used as constructors should
not return a value. (reword)
probably wouldn't hurt much code out there.
What could it hurt? What would get broken?
Benefits:
1) can crawl up the constructors without having to bake the
functionality into your library,
2) Doesn't force clients to use a non-standard fix.
3) [[class]] matches constructor property
The flip side of (2) is that if it stays, a client of a library that
fixes the constructor property may have objects created by an
in-house or another third party library where the library doesn't fix
the constructor property.
The constructor property is modifiable, but you cant count on third
party libraries using the same modification (I call it a nonstandard
fix) to the constructor property.
ES4 ref impl seems a bit off:
(new function F(){}).constructor
[function Function]
new Date(9e9).constructor
[class Class]
1['constructor']
[class Class]
It appears that es4 ref impl has the correct result for instancof on primitives
All are true in ES4 and false in ES3:
true instanceof Boolean
oo instanceof String
2 instanceof Number
null instanceof Object
NaN instanceof Number
Number.Infinity instanceof Number
I think the change is correct. if typeof b == boolean, b instanceof
boolean seems like it must be true.
I would like to understand why it was not working right in ES3-, if
someone can explain.
Garrett
David liorean Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)
On 9/23/07, liorean [EMAIL PROTECTED] wrote:
On 23/09/2007, Garrett Smith [EMAIL PROTECTED] wrote:
2. (new function(){}).constructor should be Function.
On Sep 23, 2007, at 8:59 AM, liorean wrote:
I agree. And in ES3 it is, unless the function either:
On 23/09/2007, Brendan Eich [EMAIL PROTECTED] wrote:
No:
js (new function(){}).constructor
function () {
}
js function C(){}
js new C().constructor
function C() {
}
Ah, my mistake there, was thinking of (function(){}).constructor for a
moment there.
in no case is the value of (new function(){}).constructor Function.
It shouldn't be, but it is in OSX Ref Impl. (I did not build this).
js (new function(){}).constructor
[function Function]
Thinking about it with the new keyword in mind, I just realise that
what Garrett suggested makes no sense anyway - the function object is
the constructor. The function object is an instance of Function, but
the resulting object is an instance of the function object. Making the
object have Function as it's constructor property breaks the
prototype-constructor relationship.
Correctly corrected.
In the following example:
function F(){}
F.prototype.constructor = F;
F.prototype.propertyIsEnumerable(constructor); // false, it's set to
{DontEnum} in step 10. Object.prototype.
F.prototype.constructor === F; //true
F.prototype = {
constructor : F
};
F.prototype.constructor === F; // false
F.prototype.propertyIsEnumerable(constructor); // true, now
F.prototype is an object
F.prototype is assigned to a new Object. The new Object goes through
[[construct]] getting its [[class]] property to Object. Object
instances get the constructor property from Object.prototype. The only
exception being prototype properties of Function objects, where the
constructor is flagged DontEnum.
The constructor property of an object doesn't reflect the constructor
that called it.
Garrett
On 23/09/2007, Garrett Smith [EMAIL PROTECTED] wrote:
It appears that es4 ref impl has the correct result for instancof
on primitives
On Sep 23, 2007, at 8:59 AM, liorean wrote:
A bugfix, IIRC.
On 23/09/2007, Brendan Eich [EMAIL PROTECTED] wrote:
Incompatbile enough that we are not taking the chance -- we are
changing this to match ES1-3, and to avoid boolean : Boolean etc.
Sad to hear that, but I guess compatibility will have to rule here.
So it's going back, to (true instanceof Boolean == false), huh ?
--
David liorean Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)
On 9/23/07, liorean [EMAIL PROTECTED] wrote:
On 23/09/2007, Garrett Smith [EMAIL PROTECTED] wrote:
Function objects get a non-enumerable constructor.
function F(){};
F.constructor === Function; // true
F.prototype.hasOwnProperty('constructor'); //true
F.prototype.propertyIsEnumerable(constructor); // false.
Of course.
F.prototype = {
constructor : F
}
F.prototype.propertyIsEnumerable(constructor);
Object instances don't, unless it's a prototype object created by
[[construct]]
(new F).constructor === F.constructor; // true. Undesirable
Wrong, it's false.
(new F).constructor === F.constructor; // = false
(new F).constructor === F.prototype.constructor; // = true
Right.
This works fine for shallow inheritance
Objects don't get a constructor
In what way do you mean they don't? Their constructor is the Object
object, as you show next:
({}).constructor === Object.prototype.constructor; // True.
({}).hasOwnProperty(constructor); //false.
{} is the same as new Object;
new Object goes through [[construct]]
The instance does not get a constructor property. No object instance
does. Well, none except objects that are prototype properties that
went through [[construct]]. This is confusing and makes the language
less clear to developers. It confuses me.
On 23/09/2007, Garrett Smith [EMAIL PROTECTED] wrote:
1. The constructor property should be on the object instance *created*
by the function.
On 9/23/07, liorean [EMAIL PROTECTED] wrote:
That argument I agree with. It should be on the instance and not the
prototype.
On 23/09/2007, Garrett Smith [EMAIL PROTECTED] wrote:
Which is different from the way built ins work, but seems OK.
Well, at least if you want to make sense out of the prototypal
inheritance scheme. The built ins are all single level IIRC,k and
don't need to set up their prototype relationship in user code. A
prototype system that didn't just clobber the old prototype when
setting up prototype chains maybe could have done it better. But that
won't happen in ECMAScript.
I don't see a problem.
var d = new Date;
d.constructor == Date; // true
d.hasOwnProperty('constructor'); // false
The proposed change would have the result of:
d.hasOwnProperty('constructor'); // true
d.isPropertyEnumerable('constructor'); // false
On 23/09/2007, Garrett Smith [EMAIL PROTECTED] wrote:
2. (new function(){}).constructor should be Function.
On 9/23/07, liorean [EMAIL PROTECTED] wrote:
I agree.
Actually I don't agree here, see my reply to Brendan earlier.
Right.
On 23/09/2007, Garrett Smith [EMAIL PROTECTED] wrote:
When there is an anonymous constructor, we have the ability to get at
the constructor property.
I don't see this as a problem -
Right. Whether or not the Function object has a name is irrelevant.
the constructor property should be the
function that actually constructed the object.
Exactly. That's what I'm talking about.
The fact that (new C).constructor === A; is true, by default of the
language, is counterintuitive.
[[construct]] gives a function instance a special prototype property.
That prototype property is an object, but not just an object, a
special object -- one that has a constructor property that is
specially flagged DontEnum. You lose that property the moment you give
a prototype property to F. Well, if the prototype property you give to
F is created through [[construct]], you don't.
You have to be careful.
F=function(){};
new F().constructor == F; // true.
F.propertyIsEnumerable(prototype); //true, Futhark and JScript say false.
F.prototype = {};
new F().constructor == F; // false.
F.prototype.constructor = F;
F.prototype.propertyIsEnumerable(constructor); // true, JScript says false.
var complaint = false;
for( var prop in new F )
complaint = true;
if(!complaint) alert('failure');
The browser support is pretty inconsistent, too.
So, if we want to be able to get at constructors at all, we can't
distinguish between how functions are derived - either we provide the
functionality, or we don't.
function expression/declaration, new Function -- the constructor
should all be Function
function FF(){}
FF.constructor === Function; // true
(Function()).constructor === Function; // true.
(new Function()).constructor === Function; // true.
The Object instance that is created in [[construct]] could have the
constructor property as DontEnum. This seems to be a compatibility
issue with ES3.
In ES3, you can't depend on the enumerability of an object's own
constructor property. This is because prototype objects have a
constructor property that is flagged DontEnum.
The idea is to make constructor a DontEnum property on all objects.
(not just ones that were created through [[construct]] to be used as
prototype properties).
constructor would be a default value given to the object in [[construct]]
What do you think?
F is an instance of Function
f is an instance of F
Function
Re: 13.2.2 [[Construct]], constructor, and [[Class]] (was __proto__)
On 9/23/07, Brendan Eich [EMAIL PROTECTED] wrote:
On Sep 23, 2007, at 12:22 PM, Garrett Smith wrote:
in no case is the value of (new function(){}).constructor Function.
It shouldn't be, but it is in OSX Ref Impl. (I did not build this).
js (new function(){}).constructor
[function Function]
No, that's just http://bugs.ecmascript.org/ticket/64 -- proof:
(new function(){}).constructor
[function Function]
(new function(){}).constructor === Function
false
f = function(){}
[function Function]
(new f).constructor === f
true
Ah, OK.
js Function().toSource()
function(){}
Works.
I usually like modifying toString anyway.
F = function(){};
F.prototype = {
toString : function() {
return Fork!;
}
};
f = new F;
f.toString()
//f.constructor
With Function.prototype.toString buggy, you need to test identity of
function objects.
Buggy or not, since functions could have different [[Scope]], testing
toString makes no sense.
Testing toSource is useful for seeing if it's a native function (eval,
or RegExp test), but Function.prototype.toSource() isn't provided in
the spec and isn't supported in JScript.
Garrett
/be
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: isPropertyEnumerable is going to stay broken?
YUI Connection Manager
for(var prop in this._http_header){
if(this._http_header.propertyIsEnumerable){
o.conn.setRequestHeader(prop,
this._http_header[prop]);
}
}
The conditional check will have the effect of filtering out all
browsers which don't support propertyIsEnumerable (effectively
breaking Safari 2).
Regardless, the proposed change to propertyIsEnumerable will have no
effect on the Connection Manager.
There is something called Moodle that seems to use propertyIsEnumerable.
propertyIsEnumerable is a seldom used method.
Have to let implementations know to change support of this feature (if
the change happens).
Flash, all browsers, Apple (konfabulator, OS), Nokia, et c.
The change might even be widely supported until 2012 for a programmer
to use, and then programmers will have to test not for
propertyIsEnumerable, but for which one.
if( propertyIsEnumerable in Object.prototype ) {
// Which propertyIsEnumerable do we have?
if( isPropertyIsEnumearablePrototypeEnabled() ) {
if( obj.propertyIsEnumerable( prop ) ) {
}
}
}
var isPropertyIsEnumearablePrototypeEnabled = function() {
var o = function(){};
var garbage = ~~~__0*;
o.prototype[ garbage ] = true;
var supported = o.propertyIsEnumerable( garbage );
return supported;
}
Garrett
On 9/16/07, Bob Clary [EMAIL PROTECTED] wrote:
In a fairly limited scan totaling about 3000 pages of the homepages of
33 top sites including those pages linked from the homepages I found
three occurrences of essentially the same script:
http://kaden.yahoo.co.jp/js/connection/connection-min.js
http://cn.yimg.com/i/js/ycnconn.js
http://cn.yimg.com/ncp/fashion/js3/ycnconn.js
where propertyIsEnumerable is used incorrectly (as a property rather
than as a function) but which appears to have intended to get the don't
search prototype behavior.
Due to the nature of the scan (using the narcissus parser in the
browser), the scan was fairly slow. I can use a different approach and
cover more pages if there is more interest. If not, I'll let this rest here.
Brendan Eich wrote:
On Sep 8, 2007, at 10:06 PM, Garrett Smith wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=57048
In this bug, dated 2000, Brendan and David agreed that
isPropertyEnumerable should check the prototype chain.
That was a long time ago, and while David Flanagan carries a lot of
weight with many folks, he was not on ECMA TC39 TG1, and no one on the
group changed the spec.
A lot of water under the bridge since then.
It should not backwards compatibility,
Famous last words. :-)
We try to spider the web (Alexa top 1000 and the like) looking for
counterexamples to such claims, and if we fail to find any, or better,
we find instances of confusion where the incompatible fix is assumed
(i.e., the JS author thought the spec worked the way we want to change
it to work), then we have some confidence, but not much more, in favor
of making an incompatible change. In general. In this case, no one has
done such a scan. I'll see if I can get one started.
but such functionality in the
language seems necessary. How to check enumerable attribute, including
the prototype chain?
Either reflect the __proto__ (read-only, please) property as some
implementations do, or hardcode the prototype structure and code your
propertyIsEnumerable tests accordingly.
/be
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Fwd: isPropertyEnumerable is going to stay broken?
(fwd to list)...
On 9/10/07, Brendan Eich [EMAIL PROTECTED] wrote:
On Sep 10, 2007, at 2:41 PM, Neil Mix wrote:
I think this is what Garrett is referring to:
js function f() {}
js f.prototype.foo = blah;
blah
js var x = new f();
js print(x.propertyIsEnumerable(foo));
false
js for (var n in x) print(n);
foo
And I have to agree with him, the method is confusing.
Sure, but that ship sailed (https://bugzilla.mozilla.org/show_bug.cgi?
id=57048#c4).
Based on its
name, I'd expect it to return true if the property can be enumerated
via for-in loop on the given object, regardless of where the property
exists in the prototype chain.
My question remains: is this an incompatible change that will help
more than it hurts, and otherwise be worth making?
Probably have more important things in the language.
I read that bug rep't and you stated in the last comment I still
think ECMA is wrong, and should be fixed.
I'm considering your question.
I would like it to be fixed, but can't say if it's the Right Thing.
I'll consider brining it up on c.l.j
I'm going to make a blog entry about it, too.
Garrett
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: isPropertyEnumerable is going to stay broken?
On 9/10/07, Brendan Eich [EMAIL PROTECTED] wrote:
On Sep 10, 2007, at 2:21 PM, Garrett Smith wrote:
And my point was that it appears to duplicate functionality of
hasOwnProperty in a differently named method.
The two functions are different:
js var Op = Object.prototype;
js Op.foo = 42;
42
js print(Op.hasOwnProperty('foo'), Op.propertyIsEnumerable('foo'));
true true
js print(Op.hasOwnProperty('toString'), Op.propertyIsEnumerable
('toString'));
true false
The fact that the method
was called propertyIsEnumerable instead of isPropertyEnumerable is not
great, but the way propertyIsEnumerable is designed is confusing to
developers.
I've never heard that complaint directly, or in a
bugzilla.mozilla.org report. Can you cite complaints anywhere on the
web? I believe you, but it would be good to have evidence.
propertyIsEnumerable and hasOwnProperty are interchangeable (in
conforming hosts, not JScript)
This statement is false.
You're example clarifies that. I see how it could be useful, in fact,
for examining a prototype chain to filter out extra stuff that got
shoved in.
For user-defined objects, propertyIsEnumerable and hasOwnProperty are
interchangeable.
var obj = {
Garrett : monkeybrains
,borked : javascript // transitivity fixed :-)
,toString : function() { return an enumerable prop; }
,valueOf : function() { return 2; } // also enumerable.
};
Is there a value for s where the following is true:
(obj.hasOwnProperty( s ) != obj.propertyIsEnumerable( s ))
Garrett
/be
--
Programming is a collaborative art.
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: isPropertyEnumerable is going to stay broken?
sorry, propertyIsEnumerable. On 9/8/07, Garrett Smith [EMAIL PROTECTED] wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=57048 In this bug, dated 2000, Brendan and David agreed that isPropertyEnumerable should check the prototype chain. It should not backwards compatibility, but such functionality in the language seems necessary. How to check enumerable attribute, including the prototype chain? http://wiki.ecmascript.org/doku.php?id=spec:chapter_19_native_objects#object_objects Garrett -- Programming is a collaborative art. -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
URI Proposal
I've decided to propose a URI class to deal with the handling of URIs that is so prevalent in Ajax apps and also in Flash and to a lesser extent, Adobe Reader. I propose this idea here because noticed that there are other places besides the web that can use it (Flash, Reader). A URI class could be implemented in ES to cover all these needs. I have a proposal page at http://www.dhtmlkitchen.com/rec/URI.html I won't copy paste the entire thing here. It prints on 3 pages if you set margin to 0 and scale to 70%. Is this the appropriate way to make a proposal? Garrett -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
DateFormatter (was JSON Methods)
On 9/3/07, Lars T Hansen [EMAIL PROTECTED] wrote: On 9/3/07, Garrett Smith [EMAIL PROTECTED] wrote: On 9/3/07, Lars T Hansen [EMAIL PROTECTED] wrote: On 9/2/07, Garrett Smith [EMAIL PROTECTED] wrote: snip As we say around here, some prefer the mother and some prefer the daughter. There's no accounting for taste. etc. That said, the Date class isn't an object of adoration in committee meetings. Yet what's done is done. A DateFormatter would be quite useful for parse/format functionality. I can think of a few times when I have worked with buggy hand-rolled dateFormatters (and refactored the implementation code to use a SimpleDateFormat (Java) on the server). http://java.sun.com/javase/6/docs/api/java/text/SimpleDateFormat.html (this deserves a new thread) Garrett -- Programming is a collaborative art. Your remarks have been noted. We'll see where it goes. --lars -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: some errata in PDF
On 8/26/07, Lars T Hansen [EMAIL PROTECTED] wrote: On 8/26/07, Garrett Smith [EMAIL PROTECTED] wrote: http://developer.mozilla.org/es4/spec/spec.html Bottom of the page. I found that it was convenient for printing. Am I'm reading another out-of-date spec? Very. This is the baseline spec, derived from the ActionScript 3 spec, somewhat updated (maybe) but not current in any sense that I'm aware of. Is there a version of the spec that's printable as one document? It is easier for me tor read these docs printed out on paper. Everyone, I'm removing the link to this spec, the confusion of having it there does us no good. Go to: http://www.ecmascript.org/docs.php click: ECMAScript Edition 4 Wiki this will take you to: http://developer.mozilla.org/es4/ Where you can click on the outdated specification, download it, print it out (hey, trees aren't free), and absorb the knowledge of an out-dated spec. Where, if it exists, is the indication that any of this is out of date? Garrett --lars Garrett On 8/25/07, Lars T Hansen [EMAIL PROTECTED] wrote: Which PDF spec? (We're writing the spec now, nothing has been published yet.) --lars On 8/26/07, Garrett Smith [EMAIL PROTECTED] wrote: PDF Spec: Pages 163 - 168 Methods are not alphebetized. Many methods missing. Page 163: Missing: Object.prototype.superclass ? Missing: Function.prototype.caller Function.prototype.name ? Duplicate: Function.prototype Missing: Array extras Array.prototype.length Wrong: Array.length (the Array Function gets length off function.prototype) Page 165: Missing: String.prototype.trim Page 166 Date.prototype.toLocaletimeString should be Date.prototype.toLocaleTimeString Page 63: 10.2.1 Line 27 references a non-existant variable 'b' ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss -- http://dhtmlkitchen.com/ -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
JSON Methods?
I was wondering about the new JSON methods: Object.prototype.toJSONString String.prototype.parseJSON to me, parseJSON seems like it should not be a String prototype method. I'm thinking about other parse type of methods, like Date.parse( s ); Here, it's fairly obvious what parse should return -- A Date. A parse method always parses a string, and in any well-designed API, returns an object of the class it's bound to. We've already seen this with Date.parse(), in other languages, like Java, there are Integer.parseInt, Double.parseDouble. It seems to me to make more sense to put parseJSON on object, but then since JSON is a subset of Object, why not just put it as a subclass of Object? Object + | JSON It seems to me, that Object.prototype.toJSONString could be also implemented on a JSON instance. JSON constructor: JSON( object ) static JSON parse( s ) throws SyntaxError JSON.prototype.toString( ) JSON.prototype.isValid( ) Garrett -- Programming is a collaborative art. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Array and Object Literal Types
It would be nice to have Array literal syntax declare it's ArrayType before the declaration of the array. For example: 1. var x : ArrayString = [ foo, bar, document.title, getAnotherString() ]; 2. var x = [ foo, bar, document.title, getAnotherString() ] : String; example 1 is more clear to read because in a long array, you'd see right away what type of Array it is. Is the former syntax (or some variant thereof) going to be available? What about for Objects? Garrett ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Separating a Hash type from Object
On 7/25/07, Lars T Hansen [EMAIL PROTECTED] wrote:
On 7/25/07, Garrett [EMAIL PROTECTED] wrote:
Lars T Hansen-2 wrote:
On 7/25/07, Garrett [EMAIL PROTECTED] wrote:
I see this as two issues.
1) The need for Collections/Data Structures.
2) The desire for shorthand access to these.
Indeed. We've decided to support (1) but not (2), but to sweeten our
solution by providing constructions and conversions from arbitrary
objects, so you can say
new Dict.Name,int({a: 1, b: 2, c: 3})
What is Name? Is that a new type that I haven't seen yet? Looks like an
Identifier.
I don't see Name here:
http://developer.mozilla.org/es4/spec/chapter_19_native_objects.html
(That page could benefit from a TOC and alphabetization.)
Indeed it could.
The wiki is pretty much out of sync with reality at this point; we
need to republish the internal wiki but haven't for a while, for
various reasons having to do with manpower etc. Hopefully soon.
A Name is a data structure that holds a namespace and an identifier as
separate entities. I misspoke above, there is a more general type
called EnumerableId that covers all the valid cases for a property
name in an object (Name, uint, int, and string), so the type in
question is Dict.EnumerableId,int in the example.
We're discussing whether to accomodate a hashcode/equals protocol on
keys, but if so this is guaranteed not to be the only protocol, and
we're not putting these protocols into Object, which will likely
reduce their utility a little.
The reason for adding them to Object.prototype is to have a common interface
for collections to compare objects with. The default behavior would be
strict equality.
I understand the motivation, but I don't think we'll be adding new
names to Object -- it's far too easy to break existing content, even
if these are DontEnum. The global object probably needs to be an
Object of some sort, and suddenly equals and hashcode will show up
in the global environment because of that. Tests for 'equals' in
anything will suddenly return true. etc. It's a tough sell. What
I have *proposed* for Dict is that we make it possible for clients who
want to use this OOP-like protocol to use it, and since we define what
that protocol would be then at least there's a standard for it, but
there will necessarily be some facility for supplying hashcode and
equality functions to the Dict constructor as well (defaulting to
intrinsic::hashcode and intrinsic::===) in cases where the protocol is
impossible or undesirable.
The case for HashMap: HashMap is that it is the most common type of
collection that will be used. Dictionary is more flexible, but since the
keys are not, by default, strings, it will require more work to serialize
toJSONString. In most cases users will want Strings for keys.
I think you have an uphill battle in restricting the functionality of
Dict, esp since one can say
type HashMap.T = Dict.String,T;
and be done with it. Not hard for the user, really. Although I
suppose it is an interesting idea to provide that type by default, in
addition to Dict.
It's a good point that Dict ought to have a reasonable toJSONString,
and it's true that for String keys it can do a particularly good job.
I'll be sure to add that to the proposal.
(It actually opens up interesting questions about JSON -- the current
JSON code from Doug Crockford relies on enumeration to get property
names, but then filters the enumerated properties through
hasOwnProperty.
That's for ES3.
So even when Dict provides an iterator, it would need
to provide an override for hasOwnProperty to work correctly with the
default JSON protocol, if it does not want to override toJSONString.)
var stuff = new HashTable.String, *();
stuff.add( one, 1 );
stuff.hasOwnProperty( one ); // false.
stuff.one;// undefined.
one in stuff; // false.
if( one in stuff.keys ) stuff.get( one ); // 1.
for( var key in stuff.keys ) {
print( key + : + stuff[ key ] );
}
// one: 1.
Should all Collections have a toJSONString?
Collection
|
+HashTable, SortedSet TreeMap ?
(I don't much care for Dict as a name myself, but BiCaptialized
suggestions like HashMap and hashCode won't get you anywhere with this
committee ;-)
The current JS spec is camelCasing everything. I usually like it when
an API does one thing consistently. If it's underscores, then always
use underscore, et c. JavaScript (hey, that's camel'd, too!) alway
uses camelCase. The DOM stuff is consistent, too (textContent,
nodeValue, et c). Will adding an inconsistency add confusion?
What about ByteArray, toString, toJSONString, valueOf, et c? If that's not
camelCase, I'm confused.
I'm sorry, I was being flip. We've been deriding Java's choice of
hashCode for a method name (vs hashcode in ES4), but the examples
you cite are just as awful. The splinter in your brother's eye and
the beam in your own and
