Re: 'switch' operator improvement
switch( obj ) {
case instanceof String:
break;
case instanceof Number:
break;
}
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: instanceof Operator
Does instanceof operator check 'constructor' property in [proto] chain?
- Original Message -
From: liorean [EMAIL PROTECTED]
To: es4-discuss@mozilla.org
Sent: Sunday, October 21, 2007 8:03 PM
Subject: Re: instanceof Operator
On 21/10/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
var a;
a= {};
a instanceof Object //true
a= [];
a instanceof Array //true
a='asdf';
a instanceof String //false
a= 7;
a instanceof Number //false
Why?
Because those are primitives of type double and string respectively.
They are not instances of any of the compound types Object, String or
Number.
Something silly that JavaScript inherited from Java that the world
would be much better off without, but as I understand it won't be
corrected because of real world compatibility problems.
--
David liorean Andersson
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: instanceof Operator
On 10/21/07, Jeff Dyer [EMAIL PROTECTED] wrote:
On 10/21/07 10:03 AM, liorean wrote:
On 21/10/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
var a;
a= {};
a instanceof Object //true
a= [];
a instanceof Array //true
a='asdf';
a instanceof String //false
a= 7;
a instanceof Number //false
Why?
Because those are primitives of type double and string respectively.
They are not instances of any of the compound types Object, String or
Number.
Something silly that JavaScript inherited from Java that the world
would be much better off without, but as I understand it won't be
corrected because of real world compatibility problems.
This problem is fixed by the addition of the 'is' operator in ES4. Replace
'instanceof' with 'is' in all of the above, and the result will be true in
each case. You correctly point out that 'instanceof' is terminally broken
for compatibility's sake.
I don't think is fixes it, because string is not a subclass of
String (for compatibility reasons) and abcd is string. However,
abcd is string = true
abcd instanceof string = true
The wrapper classes String, Number, Boolean are similar to the
(primitive) values they wrap, but they're not really related to those
value types in a type sense, and in ES4 the wrappers are of even less
utility than in ES3, I would say.
--lars
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: instanceof Operator
On 10/21/07 11:34 AM, Lars T Hansen wrote:
On 10/21/07, Jeff Dyer [EMAIL PROTECTED] wrote:
On 10/21/07 10:03 AM, liorean wrote:
On 21/10/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
var a;
a= {};
a instanceof Object //true
a= [];
a instanceof Array //true
a='asdf';
a instanceof String //false
a= 7;
a instanceof Number //false
Why?
Because those are primitives of type double and string respectively.
They are not instances of any of the compound types Object, String or
Number.
Something silly that JavaScript inherited from Java that the world
would be much better off without, but as I understand it won't be
corrected because of real world compatibility problems.
This problem is fixed by the addition of the 'is' operator in ES4. Replace
'instanceof' with 'is' in all of the above, and the result will be true in
each case. You correctly point out that 'instanceof' is terminally broken
for compatibility's sake.
I don't think is fixes it, because string is not a subclass of
String (for compatibility reasons) and abcd is string. However,
abcd is string = true
abcd instanceof string = true
The wrapper classes String, Number, Boolean are similar to the
(primitive) values they wrap, but they're not really related to those
value types in a type sense, and in ES4 the wrappers are of even less
utility than in ES3, I would say.
Right, thanks for the correction. This is an obvious consequence of the
recent return of primitive wrappers to ES4. 'string' is the new 'String'!
Jd
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
is ES4 getting too bloated?
Hey all, I've been watching ES4 development and occasionally contributing input, and I have noticed a somewhat disturbing trend. ES4 is getting ever more and more complex. I understand ES4 is a multi-paradigm language and so must be packed with features, but I don't think we want a repeat of the C++ template problem (where it took nearly a decade just to get most compilers near compliance with the C++ spec). My point is that although a significant update to ES is needed, if it takes too long to implement a conforming compiler/interpreter for it, the adoption of new features is going to be slow. Heck, I wonder how willing MS would be to provide a fully (or near enough to it) conforming interpreter for ES4 if the spec is so large. Small proposals like bug fixes and reformed with and company, or proposals that generalize syntax to make the language more elegant are perfectly fine by me. But we already have such huge features like classes, generators, namespaces, type system, and now generic functions. Perhaps we should start deferring more features to ES5? -Yuh-Ruey Chen ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: is ES4 getting too bloated?
I may be able to add some input and some experience implementing ES4. We have chosen to implement the ES4 language creating a compiler and 2 VMs one in C and one in Java. We started with a partial implementation of ES3 which did support a small subset of ES3 with classes but no VM design and a very limited library. We currently have most of the ES4 language implemented and running. While it has been hard (what challenging programming enterprise worth the effort is not difficult!), I think the language actually wears better once implemented and used, compared to trying to write a spec - which is awfully difficult. I agree the ES4 language is somewhat large and complex. The compatibility constraints with ES3 certainly take a toll in terms of freedom of change and expression. However, we've found that implementing the whole language is quite feasible in a relatively short amount of time with a reasonably small team. We started about 12 months ago and have implemented most of the language with a very small team and budget. We expect to be complete Q1 next year. Like any language, you can use the features to write incomprehensible code, but you can also use the features to write very readable, maintainable and more safe code than was ever possible with ES3. While I started with concerns like you have voiced, the more I use the language, the more I like it. What we've experienced is that while the spec may seem complicated, implementation is often more elegant than the spec may seem to predict. This is not criticism of the spec and I certainly have very high praise for the TG1 team, but we've found that while some of the spec may seem complex, actual usage is often very intuitive. Furthermore, for implementers, there is great leverage of some features across the entire language. For example: adding namespaces, packages, units, block scope and prototypes may seem quite a mouthful to express in the spec -- for implementers, there is an elegant design in all this and once you have the basics of namespaces and block scope you can more easily implement many language features such as getter/setters by using those facilities. Lastly, as an implementer, having access to the technical materials: grammar, wiki and most importantly the reference implementation and test suite, has been invaluable and greatly accelerated our efforts. Michael O'Brien Yuh-Ruey Chen wrote: Hey all, I've been watching ES4 development and occasionally contributing input, and I have noticed a somewhat disturbing trend. ES4 is getting ever more and more complex. I understand ES4 is a multi-paradigm language and so must be packed with features, but I don't think we want a repeat of the C++ template problem (where it took nearly a decade just to get most compilers near compliance with the C++ spec). My point is that although a significant update to ES is needed, if it takes too long to implement a conforming compiler/interpreter for it, the adoption of new features is going to be slow. Heck, I wonder how willing MS would be to provide a fully (or near enough to it) conforming interpreter for ES4 if the spec is so large. Small proposals like bug fixes and reformed with and company, or proposals that generalize syntax to make the language more elegant are perfectly fine by me. But we already have such huge features like classes, generators, namespaces, type system, and now generic functions. Perhaps we should start deferring more features to ES5? -Yuh-Ruey Chen ___ 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: 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?
Don't get me wrong - I love most of the new features (some others I'm just indifferent too). But I'm not implementing the interpreter; I would be a user of it. My concern is that of the implementator's burden, and from my point of view, if it takes a long time to implement ES4, it'll be a long time before I can get to use ES4 in practice. What Michael O'Brien just posted sounds very promising though. I haven't had the time to look at the whole spec as a whole, and since the spec is rather disorganized atm with a bunch of proposals, I'd have a hard time doing that in any case. But what I've seen so far is pretty good. I do kind of feel that there is some redundancy, i.e. there are distinct features that seem to overlap a lot. For example, packages and namespaces are both used to make programs more modular, albeit in different ways. Likewise for program units and packages. But like I said, I don't have a clear view of the spec as a whole, so I'll wait until there are good prose sections describing the usage of features before coming to a conclusion. -Yuh-Ruey Chen Garrett Smith wrote: On 10/21/07, Yuh-Ruey Chen [EMAIL PROTECTED] wrote: Hey all, I've been watching ES4 development and occasionally contributing input, and I have noticed a somewhat disturbing trend. ES4 is getting ever more and more complex. I understand ES4 is a multi-paradigm language and so must be packed with features, but I don't think we want a repeat of the C++ template problem (where it took nearly a decade just to get most compilers near compliance with the C++ spec). My point is that although a significant update to ES is needed, if it takes too long to implement a conforming compiler/interpreter for it, the adoption of new features is going to be slow. Heck, I wonder how willing MS would be to provide a fully (or near enough to it) conforming interpreter for ES4 if the spec is so large. Tamarin will be included as a plugin for IE. Small proposals like bug fixes and reformed with and company, or proposals that generalize syntax to make the language more elegant are perfectly fine by me. But we already have such huge features like classes, generators, namespaces, type system, and now generic functions. Perhaps we should start deferring more features to ES5? Which features do you feel are unjustified? Can you bring a specific issue? ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: is ES4 getting too bloated?
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. /be ___ 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
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.
YAHOO.mst.app.code = (function(){
// 1100+ lines...
I don't think this doesn't have anything to do with the topic.
Kris
___
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
