Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #27962 > unrolled thread

Re: Style: new String( "abc" )

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Style: new String( "abc" ) Andreas Bergmaier <andber93@web.de> - 2015-06-02 21:25 +0200
    Re: Style: new String( "abc" ) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-02 22:27 +0200
      Re: Style: new String( "abc" ) Andreas Bergmaier <andber93@web.de> - 2015-06-02 23:51 +0200
        Re: Style: new String( "abc" ) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-03 01:17 +0200
          Re: Style: new String( "abc" ) Andreas Bergmaier <andber93@web.de> - 2015-06-03 06:22 +0200
            Re: Style: new String( "abc" ) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-03 07:57 +0200
              Re: Style: new String( "abc" ) Andreas Bergmaier <andber93@web.de> - 2015-06-03 18:36 +0200
            Re: Style: new String( "abc" ) John Harris <niam@jghnorth.org.uk.invalid> - 2015-06-03 15:38 +0100

#27962 — Re: Style: new String( "abc" )

Stefan Ram schrieb:

>  the primitve "abc" was implicitly converted
>  into an object /three times/.

In the old times, maybe. Current compilers don't convert anything to an 
object any more here, they just call the native 
`String.prototype.charAt` method directly on the primitive value.

> Wouldn't this be more
> efficient? So, why could it be bad style?

Even efficient code can be bad style :-) (think about goto for an 
extreme example).
The wrapper creation is just unnecessary and overly verbose. With very 
little gain.

  Bergi

[toc] | [next] | [standalone]

#27964

Andreas Bergmaier wrote:

> Stefan Ram schrieb:
>>  the primitve "abc" was implicitly converted
>>  into an object /three times/.
> 
> In the old times, maybe. Current compilers don't convert anything to an
> object any more here, they just call the native
> `String.prototype.charAt` method directly on the primitive value.

Cite evidence.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27970

Thomas 'PointedEars' Lahn schrieb:
> Andreas Bergmaier wrote:
>
>> Current compilers don't convert anything to an
>> object any more here, they just call the native
>> `String.prototype.charAt` method directly on the primitive value.
>
> Cite evidence.

This should get you started: 
http://stackoverflow.com/questions/17256182/what-is-the-difference-between-string-literals-and-string-objects-in-javascript
The speed tests (http://jsperf.com/heera-string-literal-vs-object) 
linked from there speak for themselves.
You can read yourself through the V8 code, they do distinguish between 
primitive values and objects a lot to gain extra optimisations.
I couldn't locate the exact code myself, but when you have to look up a 
property on a primitive value you can directly jump to the respective 
prototype intrinsic object. There's no need to create a wrapper object, 
unless the lookup turns out to become a method call of a sloppy-mode 
function.

I also found this bug 
report:http://code.google.com/p/v8/issues/detail?id=1212 which seems to 
have been forgotten in 2011.

  Bergi

[toc] | [prev] | [next] | [standalone]

#27971

Andreas Bergmaier wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Andreas Bergmaier wrote:
>>> Current compilers don't convert anything to an
>>> object any more here, they just call the native
>>> `String.prototype.charAt` method directly on the primitive value.
>> Cite evidence.
> 
> This should get you started:
> http://stackoverflow.com/questions/17256182/what-is-the-difference-between-string-literals-and-string-objects-in-javascript

I do not see anything there that substantiates your claim.  Instead, I see 
an answer, <http://stackoverflow.com/a/17256419/855543>, that clearly 
contradicts your claim when it says:

| I'll exemplify with V8 but I assume other engines use similar approaches.
| 
| A string primitive is parsed to a v8::String object. Hence, methods can be 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^            ^^^^^^
| invoked directly on it as mentioned by jfriend00.

> The speed tests (http://jsperf.com/heera-string-literal-vs-object)
> linked from there speak for themselves.

To quote from one of my favorite books [1]:

| “/No/ data speaks for itself,” McCoy said, forceful. “Data just lies 
| there. /People/ speak. The idiom ‘speaks for itself’ almost /always/ 
| translates as ‘If I don’t say something about this, no one will notice
| it.’ Sloppy thinking, Selv! You are dealing with second- and third-hand 
| data. […]

I asked you to cite *evidence*, not inference and supposition.  Sloppy 
thinking, Andreas!

> You can read yourself through the V8 code, […]

That would be *one* "compiler", and what you cited already indicates that 
your claim does not apply to it in particular.

_________
[1] Diane DUANE. Spock’s World. Pocket Books, 1986. ISBN 9780671041137.
    p. 296
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27972

Thomas 'PointedEars' Lahn schrieb:
> Andreas Bergmaier wrote:
>
>> This should get you started:
>> http://stackoverflow.com/questions/17256182/what-is-the-difference-between-string-literals-and-string-objects-in-javascript
>
> I do not see anything there that substantiates your claim.  Instead, I see
> an answer, <http://stackoverflow.com/a/17256419/855543>, that clearly
> contradicts your claim when it says:
>
> | I'll exemplify with V8 but I assume other engines use similar approaches.
> |
> | A string primitive is parsed to a v8::String object. Hence, methods can be
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^            ^^^^^^
> | invoked directly on it as mentioned by jfriend00.

I'd assume you've read the next two sentences as well?

Yes, primitive strings are represented as C++ objects in V8 - because 
sequences of characters can become quite complex, and you might want to 
intern them and everything. An OOP approach seems suitable here, and I'm 
not even sure whether a std::c_str or char* would match your definition 
of primitive C++ value.
But still, those v8::String objects are primitive JS values, while in 
contrast

| A String object, in the other hand, is parsed to a v8::StringObject
| which extends Object and, apart from being a full fledged object,
| serves as a wrapper for v8::String.

So yes, StringObject objects are C++ objects as well. Understanding the 
difference between those two classes, it is clear that using String 
objects in JS

| has to unbox this v8::StringObject's v8::String before executing the
| method, hence it is slower.

  Bergi

[toc] | [prev] | [next] | [standalone]

#27973

Andreas Bergmaier wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Andreas Bergmaier wrote:
>>> This should get you started:
>>> http://stackoverflow.com/questions/17256182/what-is-the-difference-between-string-literals-and-string-objects-in-javascript
>>
>> I do not see anything there that substantiates your claim.  Instead, I
>> see an answer, <http://stackoverflow.com/a/17256419/855543>, that clearly
>> contradicts your claim when it says:
>>
>> | I'll exemplify with V8 but I assume other engines use similar
>> | approaches.
>> |
>> | A string primitive is parsed to a v8::String object. Hence, methods can
>> | be
>>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^            ^^^^^^
>> | invoked directly on it as mentioned by jfriend00.
> 
> I'd assume you've read the next two sentences as well?

I have, but they are irrelevant to your claim.

> [red herring]

> | has to unbox this v8::StringObject's v8::String before executing the
> | method, hence it is slower.

Your logic is flawed.  What you quoted does not change, it rather 
*emphasizes*, the fact that string primitives *are* parsed into objects by 
V8, which you claimed they would not be:

>>>>>> the primitve "abc" was implicitly converted into an object /three 
>>>>>> times/.
>>>>> In the old times, maybe.  Current compilers don't convert anything to 
>>>>> an object any more here, […]

  – Andreas Bergmaier in <news:mkl000$bif$1@news.albasani.net>

V8 is what can be called a “current script engine”.  So it contains a 
“current compiler”.  But that compiler *does* parse string primitives into 
(v8::String) objects.

Therefore, _not_ *all* “current compilers do not convert anything to an 
object any more there.”

Your claim has been refuted by your sources.

  “Learn reason above all.  Learn clear thought: learn to know
   what is from what seems to be, and what you wish to be.”

    ─Surak

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27978

Thomas 'PointedEars' Lahn schrieb:
> [snip]
> V8 is what can be called a “current script engine”.  So it contains a
> “current compiler”.  But that compiler *does* parse string primitives into
> (v8::String) objects.
>
> Therefore, _not_ *all* “current compilers do not convert anything to an
> object any more there.”

Maybe it would have been clearer if they had named their "String" class 
"PrimitiveString". Then we'd have v8::PrimitiveString objects, if that 
makes sense to you :-)
They're JavaScript primitive values represented as C++ objects. Which 
has nothing to do with JS type conversions, it's just the native 
implementation.

The point that Fabrício makes is that there are no JS String wrapper 
objects, which would be represented by v8::StringObject objects wrapping 
v8::"PrimitiveString" objects, created when a property on a JS primitive 
is accessed.
(And neither are there new v8::"PrimitiveString" objects created, they 
were created by the parser at compile time)

  Bergi

[toc] | [prev] | [next] | [standalone]

#27976

On 3 Jun 2015 06:31:08 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>Andreas Bergmaier <andber93@web.de> writes:
>>Yes, primitive strings are represented as C++ objects in V8
>
>  In the terminology of the language C++, when you define:
>
>int i = 7;
>
>  , then this »i« is the name of an object. So, it is hard
>  to represent something with anything else than an object
>  in C++.

That's rather misleading. In the C and C++ standards the word "object"
is defined as follows :
  "An object is a region of storage."

When a variable occupies a region of storage then it is said to be an
object. This has nothing to do with OO, especially in C.

  John

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web