'switch' operator improvement

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

'switch' operator improvement

Eugen.Konkov
allow RegEx in case
 
var str= 'a';
switch( str ) {
  case /a/:
    alert('a');
    break;
 
  case /b/:
    alert('b');
    break;
  }

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

Lars T Hansen-2
Neat, though it breaks backward compatibility -- each regexp is
converted to string before the comparison, IIRC.  (Compatibility may
not be a big problem in practice in this case.)

--lars

On 10/16/07, [hidden email] <[hidden email]> wrote:

>
>
> allow RegEx in case
>
> var str= 'a';
> switch( str ) {
>   case /a/:
>     alert('a');
>     break;
>
>   case /b/:
>     alert('b');
>     break;
>   }
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

Dave Herman-2
It's clever, but it's a special case that may not abstract very
smoothly. For example:

function f(g) {
     switch (x) {
         case g():
         ...
     }
}

The behavior of my function depends on whether g() returns a RegEx or a
non-RegEx. Maybe that's what you want, but it means it's an extra
special case that you have to be aware of whenever abstracting a case
statement.

Dave

Lars T Hansen wrote:

> Neat, though it breaks backward compatibility -- each regexp is
> converted to string before the comparison, IIRC.  (Compatibility may
> not be a big problem in practice in this case.)
>
> --lars
>
> On 10/16/07, [hidden email] <[hidden email]> wrote:
>>
>> allow RegEx in case
>>
>> var str= 'a';
>> switch( str ) {
>>   case /a/:
>>     alert('a');
>>     break;
>>
>>   case /b/:
>>     alert('b');
>>     break;
>>   }
>>
>> _______________________________________________
>> Es4-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es4-discuss
>>
>>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

Eugen.Konkov
I think switch ... case construction must be interpreted as:
function f(g) {
 if( x == g() ) ....     // case g():
 if( ....                    //  case ...
 }

----- Original Message -----
From: "Dave Herman" <[hidden email]>
To: "Lars T Hansen" <[hidden email]>
Cc: <[hidden email]>; <[hidden email]>
Sent: Tuesday, October 16, 2007 6:04 PM
Subject: Re: 'switch' operator improvement


> It's clever, but it's a special case that may not abstract very
> smoothly. For example:
>
> function f(g) {
>     switch (x) {
>         case g():
>         ...
>     }
> }
>
> The behavior of my function depends on whether g() returns a RegEx or a
> non-RegEx. Maybe that's what you want, but it means it's an extra
> special case that you have to be aware of whenever abstracting a case
> statement.
>
> Dave
>
> Lars T Hansen wrote:
>> Neat, though it breaks backward compatibility -- each regexp is
>> converted to string before the comparison, IIRC.  (Compatibility may
>> not be a big problem in practice in this case.)
>>
>> --lars
>>
>> On 10/16/07, [hidden email] <[hidden email]> wrote:
>>>
>>> allow RegEx in case
>>>
>>> var str= 'a';
>>> switch( str ) {
>>>   case /a/:
>>>     alert('a');
>>>     break;
>>>
>>>   case /b/:
>>>     alert('b');
>>>     break;
>>>   }
>>>
>>> _______________________________________________
>>> Es4-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es4-discuss
>>>
>>>
>> _______________________________________________
>> Es4-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

Dave Herman-2
But that's not what you proposed, is it? I understood your proposal to
mean something more like:

function f(g) {
     if (let (tmp = g())    // case g():
         (tmp is RegEx ? tmp.match(x) : x == tmp)) ....
     if ....
}

Dave

[hidden email] wrote:

> I think switch ... case construction must be interpreted as:
> function f(g) {
>  if( x == g() ) ....     // case g():
>  if( ....                    //  case ...
>  }
>
> ----- Original Message -----
> From: "Dave Herman" <[hidden email]>
> To: "Lars T Hansen" <[hidden email]>
> Cc: <[hidden email]>; <[hidden email]>
> Sent: Tuesday, October 16, 2007 6:04 PM
> Subject: Re: 'switch' operator improvement
>
>
>> It's clever, but it's a special case that may not abstract very
>> smoothly. For example:
>>
>> function f(g) {
>>     switch (x) {
>>         case g():
>>         ...
>>     }
>> }
>>
>> The behavior of my function depends on whether g() returns a RegEx or a
>> non-RegEx. Maybe that's what you want, but it means it's an extra
>> special case that you have to be aware of whenever abstracting a case
>> statement.
>>
>> Dave
>>
>> Lars T Hansen wrote:
>>> Neat, though it breaks backward compatibility -- each regexp is
>>> converted to string before the comparison, IIRC.  (Compatibility may
>>> not be a big problem in practice in this case.)
>>>
>>> --lars
>>>
>>> On 10/16/07, [hidden email] <[hidden email]> wrote:
>>>> allow RegEx in case
>>>>
>>>> var str= 'a';
>>>> switch( str ) {
>>>>   case /a/:
>>>>     alert('a');
>>>>     break;
>>>>
>>>>   case /b/:
>>>>     alert('b');
>>>>     break;
>>>>   }
>>>>
>>>> _______________________________________________
>>>> Es4-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es4-discuss
>>>>
>>>>
>>> _______________________________________________
>>> Es4-discuss mailing list
>>> [hidden email]
>>> https://mail.mozilla.org/listinfo/es4-discuss
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

Peter Hall-4
Minor nitpick, but that should be "===" not "==".

I really like the idea, but probably it should be done in a way that
could be generalised beyond just the RegExp case. And that doesn't
seem like something that can be done in the es4 time-frame.

But already you can do something like this:

var str;
switch(true){
case /a/.test(str):
  alert('a');
  break;
case /b/.test(str):
  alert('b');
  break;
}

Not quite as neat or readable, but the same functionality and not
overly verbose.

I'd be interested to know how often switch statements are used in the
real-world, that could not be trivially replaced with if..else, ie
without breaks on every case. Has that been previously measured?

Peter


On 10/16/07, Dave Herman <[hidden email]> wrote:

> But that's not what you proposed, is it? I understood your proposal to
> mean something more like:
>
> function f(g) {
>      if (let (tmp = g())    // case g():
>          (tmp is RegEx ? tmp.match(x) : x == tmp)) ....
>      if ....
> }
>
> Dave
>
> [hidden email] wrote:
> > I think switch ... case construction must be interpreted as:
> > function f(g) {
> >  if( x == g() ) ....     // case g():
> >  if( ....                    //  case ...
> >  }
> >
> > ----- Original Message -----
> > From: "Dave Herman" <[hidden email]>
> > To: "Lars T Hansen" <[hidden email]>
> > Cc: <[hidden email]>; <[hidden email]>
> > Sent: Tuesday, October 16, 2007 6:04 PM
> > Subject: Re: 'switch' operator improvement
> >
> >
> >> It's clever, but it's a special case that may not abstract very
> >> smoothly. For example:
> >>
> >> function f(g) {
> >>     switch (x) {
> >>         case g():
> >>         ...
> >>     }
> >> }
> >>
> >> The behavior of my function depends on whether g() returns a RegEx or a
> >> non-RegEx. Maybe that's what you want, but it means it's an extra
> >> special case that you have to be aware of whenever abstracting a case
> >> statement.
> >>
> >> Dave
> >>
> >> Lars T Hansen wrote:
> >>> Neat, though it breaks backward compatibility -- each regexp is
> >>> converted to string before the comparison, IIRC.  (Compatibility may
> >>> not be a big problem in practice in this case.)
> >>>
> >>> --lars
> >>>
> >>> On 10/16/07, [hidden email] <[hidden email]> wrote:
> >>>> allow RegEx in case
> >>>>
> >>>> var str= 'a';
> >>>> switch( str ) {
> >>>>   case /a/:
> >>>>     alert('a');
> >>>>     break;
> >>>>
> >>>>   case /b/:
> >>>>     alert('b');
> >>>>     break;
> >>>>   }
> >>>>
> >>>> _______________________________________________
> >>>> Es4-discuss mailing list
> >>>> [hidden email]
> >>>> https://mail.mozilla.org/listinfo/es4-discuss
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Es4-discuss mailing list
> >>> [hidden email]
> >>> https://mail.mozilla.org/listinfo/es4-discuss
> > _______________________________________________
> > Es4-discuss mailing list
> > [hidden email]
> > https://mail.mozilla.org/listinfo/es4-discuss
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

Brendan Eich-2
In reply to this post by Dave Herman-2
On Oct 16, 2007, at 8:19 AM, Dave Herman wrote:

> But that's not what you proposed, is it? I understood your proposal to
> mean something more like:
>
> function f(g) {
>      if (let (tmp = g())    // case g():
>          (tmp is RegEx ? tmp.match(x) : x == tmp)) ....
>      if ....
> }
>
> Dave

Right, and that is not only backward incompatible, but user-hostile  
unless you type everything. It's perl-ish magic.

I say use an if-else and call match if that is what you want. EIBTI,  
the Pythonistas say (Explicit Is Better Than Implicit).

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

liorean
In reply to this post by Peter Hall-4
On 16/10/2007, Peter Hall <[hidden email]> wrote:

> already you can do something like this:
>
> var str;
> switch(true){
> case /a/.test(str):
>   alert('a');
>   break;
> case /b/.test(str):
>   alert('b');
>   break;
> }

I can only imagine that solution being preferable to chained
if..else-statements in one case, and that would be if you actually
used the fall through mechanism. If you don't fall through, it's just
bloat without any gain.
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

David Teller-3
Pattern-matching with views [1,2], anyone ?

Cheers,
 David

[1] http://martin.jambon.free.fr/micmatch-manual.html#htoc10
[2] http://blogs.msdn.com/dsyme/archive/2006/08/16/ActivePatterns.aspx

On Tue, 2007-10-16 at 20:11 +0200, liorean wrote:

> On 16/10/2007, Peter Hall <[hidden email]> wrote:
> > already you can do something like this:
> >
> > var str;
> > switch(true){
> > case /a/.test(str):
> >   alert('a');
> >   break;
> > case /b/.test(str):
> >   alert('b');
> >   break;
> > }
>
> I can only imagine that solution being preferable to chained
> if..else-statements in one case, and that would be if you actually
> used the fall through mechanism. If you don't fall through, it's just
> bloat without any gain.
--
David Teller ------------------------------------------
Security of Distributed Systems -----------------------
Project JStify: Static Analysis for JavaScript 2  -----
-- http://www.univ-orleans.fr/lifo/Members/David.Teller
----- Laboratoire d'Informatique Fondamentale d'Orleans

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

Eugen.Konkov
In reply to this post by Dave Herman-2
I think this is the best:
1) Variable in 'switch' is parameter for case
2) 'case' triggers if result of case expression is 'true'
So.
switch( aaa )
  case <some expression>:
  case <another expression>:
  ...

After JS processing
if( <modified some expression> ) {
if( <another modified expression> ) {


----- Original Message -----
From: "Dave Herman" <[hidden email]>
To: <[hidden email]>
Cc: "Lars T Hansen" <[hidden email]>; <[hidden email]>
Sent: Tuesday, October 16, 2007 6:19 PM
Subject: Re: 'switch' operator improvement


> But that's not what you proposed, is it? I understood your proposal to
> mean something more like:
>
> function f(g) {
>     if (let (tmp = g())    // case g():
>         (tmp is RegEx ? tmp.match(x) : x == tmp)) ....
>     if ....
> }
>
> Dave
>
> [hidden email] wrote:
>> I think switch ... case construction must be interpreted as:
>> function f(g) {
>>  if( x == g() ) ....     // case g():
>>  if( ....                    //  case ...
>>  }
>>
>> ----- Original Message -----
>> From: "Dave Herman" <[hidden email]>
>> To: "Lars T Hansen" <[hidden email]>
>> Cc: <[hidden email]>; <[hidden email]>
>> Sent: Tuesday, October 16, 2007 6:04 PM
>> Subject: Re: 'switch' operator improvement
>>
>>
>>> It's clever, but it's a special case that may not abstract very
>>> smoothly. For example:
>>>
>>> function f(g) {
>>>     switch (x) {
>>>         case g():
>>>         ...
>>>     }
>>> }
>>>
>>> The behavior of my function depends on whether g() returns a RegEx or a
>>> non-RegEx. Maybe that's what you want, but it means it's an extra
>>> special case that you have to be aware of whenever abstracting a case
>>> statement.
>>>
>>> Dave
>>>
>>> Lars T Hansen wrote:
>>>> Neat, though it breaks backward compatibility -- each regexp is
>>>> converted to string before the comparison, IIRC.  (Compatibility may
>>>> not be a big problem in practice in this case.)
>>>>
>>>> --lars
>>>>
>>>> On 10/16/07, [hidden email] <[hidden email]> wrote:
>>>>> allow RegEx in case
>>>>>
>>>>> var str= 'a';
>>>>> switch( str ) {
>>>>>   case /a/:
>>>>>     alert('a');
>>>>>     break;
>>>>>
>>>>>   case /b/:
>>>>>     alert('b');
>>>>>     break;
>>>>>   }
>>>>>
>>>>> _______________________________________________
>>>>> Es4-discuss mailing list
>>>>> [hidden email]
>>>>> https://mail.mozilla.org/listinfo/es4-discuss
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Es4-discuss mailing list
>>>> [hidden email]
>>>> https://mail.mozilla.org/listinfo/es4-discuss
>> _______________________________________________
>> Es4-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es4-discuss
>

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: 'switch' operator improvement

Eugen.Konkov
In reply to this post by liorean
switch( obj ) {
  case instanceof String:
    ....
    break;
     
  case instanceof Number:
    ....
    break;
     
  }
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

instanceof Operator

Eugen.Konkov
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?
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: instanceof Operator

liorean
On 21/10/2007, [hidden email] <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: instanceof Operator

Eugen.Konkov
Does instanceof operator check 'constructor' property in [proto] chain?

----- Original Message -----
From: "liorean" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, October 21, 2007 8:03 PM
Subject: Re: instanceof Operator


> On 21/10/2007, [hidden email] <[hidden email]> 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
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: instanceof Operator

liorean
On 21/10/2007, [hidden email] <[hidden email]> wrote:
> Does instanceof operator check 'constructor' property in [proto] chain?

No. It uses the [[HasInstance]] private method of the object passed in
as the right operand.

In the case of

    'string' instanceof String;

F is String and 'string' is V in the following algorithm:
~~~~~~~~
15.3.5.3 [[HasInstance]] (V)
Assume F is a Function object.
When the [[HasInstance]] method of F is called with value V, the
following steps are taken:
1. If V is not an object, return false.
2. Call the [[Get]] method of F with property name "prototype".
3. Let O be Result(2).
4. If O is not an object, throw a TypeError exception.
5. Let V be the value of the [[Prototype]] property of V.
6. If V is null, return false.
7. If O and V refer to the same object or if they refer to objects
joined to each other (section 13.1.2), return true.
8. Go to step 5.
~~~~~~~~
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: instanceof Operator

Jeff Dyer
In reply to this post by liorean



On 10/21/07 10:03 AM, liorean wrote:

> On 21/10/2007, [hidden email] <[hidden email]> 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.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: instanceof Operator

Lars T Hansen-2
On 10/21/07, Jeff Dyer <[hidden email]> wrote:

>
> On 10/21/07 10:03 AM, liorean wrote:
>
> > On 21/10/2007, [hidden email] <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: instanceof Operator

Jeff Dyer



On 10/21/07 11:34 AM, Lars T Hansen wrote:

> On 10/21/07, Jeff Dyer <[hidden email]> wrote:
>>
>> On 10/21/07 10:03 AM, liorean wrote:
>>
>>> On 21/10/2007, [hidden email] <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: instanceof Operator

Brendan Eich-2
On Oct 21, 2007, at 11:48 AM, Jeff Dyer wrote:

>> 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'!

String has its uses, not just embedded in content that requires  
compatibility: string and String inter-convert, String is non-final,  
and the two share a prototype object.

The need for string comes directly from ES1-3, because the primitive  
string type in JS1 was auto-wrapped when you used a string value as  
if it were an object, say to call a method on it. But since a new  
wrapper was created each time (or so it appeared; implementations  
could optimize), the object-ness of the primitive string was  
ephemeral: you couldn't set methods and get them later; any get on  
the wrapper for a property not found on String.prototype or above  
would return undefined.

In ES4, string has catchalls to satisfy this ephemeral wrapper get/
set compatibility, but method calls on string instances do not  
require String wrapper creation.

Wrapper creation may or may not be observable in ES3 -- 9.9 says  
"create a new String" but does not say by evaluating |String| in  
order to construct -- but ES4 does not allow any type name to be re-
bound, so the implementations that chose to construct the wrapper by  
reflecting on the current value of 'String' in the global object,  
thereby allowing someone to replace that binding and spy on wrapper  
construction, no longer need to reflect each time.

The shared prototype object allows for replacement of prototype  
methods, which per ES1-3 and much compatibility-constraining content  
on the web, remain mutably bound in the shared prototype object. Thus  
in ES1-3, if you wrapped String.prototype.charAt with some AOP advice  
function, your code calling "hi".charAt(0) will still run your advice.

Since ("hi instanceof String) was never true, it should not be true  
in the new world. This is one reason string and String are peer  
subtypes of Object, that is, string is not a subtype of String.

Tucker and others have hoped for a way to customize String, and since  
it is non-final and convertible to string, the use-cases that want to  
make custom objects that delegate to String.prototype should work  
too. But it would be good to see some examples.

/be
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: instanceof Operator

P T Withington
In reply to this post by Jeff Dyer
On 2007-10-21, at 14:48 EDT, Jeff Dyer wrote:

>>
>> 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'!

Yikes.  I thought 'String' was being kept around so you could extend  
it.  Why is it that 'string' cannot be a sealed sub-type of (the open  
class) 'String'?

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12