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

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

Re: JavaScript + DOM, type system

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: JavaScript + DOM, type system "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-11-20 00:01 +0100
    Re: JavaScript + DOM, type system "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-11-19 18:47 -0800
      Re: JavaScript + DOM, type system Andrew Poulos <ap_prog@hotmail.com> - 2020-11-20 16:29 +1100
        Re: JavaScript + DOM, type system "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-11-20 14:46 +0100
          Re: JavaScript + DOM, type system JJ <jj4public@gmail.com> - 2020-11-21 14:47 +0700
            Re: JavaScript + DOM, type system Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2020-11-21 23:27 +0100
              Re: JavaScript + DOM, type system "sc...@sauyet.com" <scott@sauyet.com> - 2020-12-02 11:04 -0800

#39160 — Re: JavaScript + DOM, type system

ram@zedat.fu-berlin.de (Stefan Ram) wrote on 19 Nov 2020 in 
comp.lang.javascript:

>   When "a" is an element,
> 
> a.textContent = 4
> 
>   seems to behave like
> 
> a.textContent = "4"
> 
>   , but is there any specification giving the meaning of the
>   assignment of a number of JavaScript to the textContent
>   attribute of the DOM?

The text-content of a Dom-node must be a string, logic says.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [next] | [standalone]

#39161

On Thursday, November 19, 2020 at 5:02:02 PM UTC-6, Evertjan. wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) wrote on 19 Nov 2020 in 
> comp.lang.javascript: 
> 
> > When "a" is an element, 
> > 
> > a.textContent = 4 
> > 
> > seems to behave like 
> > 
> > a.textContent = "4" 
> > 
> > , but is there any specification giving the meaning of the 
> > assignment of a number of JavaScript to the textContent 
> > attribute of the DOM? 
> 
> The text-content of a Dom-node must be a string, logic says. 

Right, and if that wasn't enough there is MDN:

<https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent>

and the IDL:

<https://www.w3.org/TR/DOM-Level-3-Core/idl-definitions.html>

depending on how formal one wants an answer

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

#39162

On 20/11/2020 1:47 pm, Michael Haufe (TNO) wrote:
> On Thursday, November 19, 2020 at 5:02:02 PM UTC-6, Evertjan. wrote:
>> r...@zedat.fu-berlin.de (Stefan Ram) wrote on 19 Nov 2020 in
>> comp.lang.javascript:
>>
>>> When "a" is an element,
>>>
>>> a.textContent = 4
>>>
>>> seems to behave like
>>>
>>> a.textContent = "4"
>>>
>>> , but is there any specification giving the meaning of the
>>> assignment of a number of JavaScript to the textContent
>>> attribute of the DOM?
>>
>> The text-content of a Dom-node must be a string, logic says.
> 
> Right, and if that wasn't enough there is MDN:
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent>
> 
> and the IDL:
> 
> <https://www.w3.org/TR/DOM-Level-3-Core/idl-definitions.html>
> 
> depending on how formal one wants an answer

I thought he was asking, why does a number get changed to, the 
equivalent of, the number + "" and not, I presume, return some sort of 
error.

Andrew Poulos

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

#39163

Andrew Poulos <ap_prog@hotmail.com> wrote on 20 Nov 2020 in 
comp.lang.javascript:

> On 20/11/2020 1:47 pm, Michael Haufe (TNO) wrote:
>> On Thursday, November 19, 2020 at 5:02:02 PM UTC-6, Evertjan. wrote:
>>> r...@zedat.fu-berlin.de (Stefan Ram) wrote on 19 Nov 2020 in
>>> comp.lang.javascript:
>>>
>>>> When "a" is an element,
>>>>
>>>> a.textContent = 4
>>>>
>>>> seems to behave like
>>>>
>>>> a.textContent = "4"
>>>>
>>>> , but is there any specification giving the meaning of the
>>>> assignment of a number of JavaScript to the textContent
>>>> attribute of the DOM?
>>>
>>> The text-content of a Dom-node must be a string, logic says.
>> 
>> Right, and if that wasn't enough there is MDN:
>> 
>> <https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent>
>> 
>> and the IDL:
>> 
>> <https://www.w3.org/TR/DOM-Level-3-Core/idl-definitions.html>
>> 
>> depending on how formal one wants an answer
> 
> I thought he was asking, why does a number get changed to, the 
> equivalent of, the number + "" and not, I presume, return some sort of 
> error.

Bbbut ...

Everything, that is written as text, must be a formatted string.

It confused me, long time ago, in Algol, why you needed always to specify 
the format of an output to a printing device.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

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

#39167

On Fri, 20 Nov 2020 14:46:44 +0100, Evertjan. wrote:
> 
> Bbbut ...
> 
> Everything, that is written as text, must be a formatted string.

Agreed.

Basically, the destination storage can only store a string, thus only accept
a string. So anything which need to be placed in that storage, needs to be
converted to a string first.

It's similar to the fact that JavaScript number type is a float number type.
So, even if an integer number is present in a code, it'll be converted to a
float number before being assigned to a number variable, or be used in a
math calculation.

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

#39168

JJ wrote:

> On Fri, 20 Nov 2020 14:46:44 +0100, Evertjan. wrote:
>> Bbbut ...
>> 
>> Everything, that is written as text, must be a formatted string.
> 
> Agreed.

How, except out of ignorance, can you agree to such nonsense?  This is 
simply not how it works.
 
> Basically, the destination storage can only store a string, thus only
> accept a string. So anything which need to be placed in that storage,
> needs to be converted to a string first.

It is far more complex than you think.  The "destination storage" is an 
implementation of an IDL attribute.  *That* is why it *makes sense* 
(although there is no requirement) to convert the value implicitly on 
assignment via a setter.  Why?  Because otherwise the conversion has to be 
done every time the property is accessed, and, as values are more often
read than written, that would reduce the efficiency of the code.

But in fact, without looking at the implementation code, one cannot say 
whether the value was actually converted on assignment as a getter can 
obscure the true type of the stored value:

                                     ,------------------------.
                                     : Element                :
            ,--------.               :========================:
  42 -------| setter |------> "42" --:-> textContent : String :
            `--------'               `------------------------'


                                     ,------------------------.
                                     : Element                :
                                     :========================:
  "42" <-----------------------------:-> textContent : String :
                                     `------------------------'

or

                                     ,---------------------.
                                     : Element             :
                                     :=====================:
  42 --------------------------------:-> textContent : any :
                                     `---------------------'

                                     ,---------------------.
                                     : Element             :
            ,--------.               :=====================:
  "42" <----| getter |-------- 42 <--:-- textContent : any :
            `--------'               `---------------------'

> It's similar to the fact that JavaScript number type is a float number
> type. So, even if an integer number is present in a code, it'll be
> converted to a float number before being assigned to a number variable,

There is no “JavaScript number type”.

There are no “number variables” unless the ECMAScript implementation is a 
special one that supports static type-checking and the variable has been 
declared accordingly.

What actually happens is that the numeric literal is interpreted as and 
*rounded to* an IEEE-754 floating-point value, and then on assignment it 
does not matter which type the developer intended the variable/property to 
have (unless there is a setter to the contrary); it will have for all 
intents and purposes, until assigned another value, the type of its value 
(unless there is a getter to the contrary), simply because its value is the 
result of evaluating it.  See, for example,

<https://www.ecma-international.org/ecma-262/10.0/index.html#sec-static-semantics-mv>

> or be used in a math calculation.

That, too, is irrelevant; a conforming ECMAScript implementation MUST NOT 
care about the developer’s intentions.  What matters instead are the 
operators that appear in expressions in which the variable identifier or 
property name is being used.  Those operators will force, if necessary, the 
conversion of the *retrieved* value (after a potential getter) to the data 
type that is required for the operation to take place as *the designers of 
the language/standard* saw fit.

It is important to understand the difference because this can have counter-
intuitive results: 1 + "2" does NOT evaluate to 3 (i.e. "2" is NOT converted 
to Number), but to "12" (i.e. 1 is converted to "1" instead), because a 
single string value in a chain of “+” operations changes the meaning of the 
operation from an addition to a string concatenation, and that requires all 
operands to be interpreted as expressions that evaluate to values of type 
String.  (So if the second operand here is coming from user input, you must 
convert it to Number explicitly if you want to use it in a *trivial* 
addition operation.)

See, for example,

<https://www.ecma-international.org/ecma-262/10.0/index.html#sec-addition-operator-plus>

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

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

#39221

Thomas 'PointedEars' Lahn wrote:

> [ ...]
> It is important to understand the difference because this can have 
> counter-intuitive results: 1 + "2" does NOT evaluate to 3 (i.e. "2"
> is NOT converted to Number), but to "12" (i.e. 1 is converted to "1"
> instead), because a single string value in a chain of “+” operations
> changes the meaning of the operation from an addition to a string 
> concatenation, and that requires all operands to be interpreted as 
> expressions that evaluate to values of type String. (So if the 
> second operand here is coming from user input, you must convert it 
> to Number explicitly if you want to use it in a *trivial* addition 
> operation.)  [ ... ]

This isn't quite right.  A single string value in a chain of `+`
operations changes the meaning of **that specific `+` operation** to
string concatenation.

So, while `"1" + 2 + 3` yields `"123"`, it does so because `+` is
left-associative and thus this is evaluated similarly to `("1" + 2) + 
3`.  When we evaluate `"1" + 2`, then this rule applies and we get
`"12"`, then in the evaluation of `"12" + 3` we again apply this rule
to get `"123"`.

But `1 + 2 + "3"` is different.  It yields `"33"`.  It is evaluated as
`(1 + 2) + "3"`,  and in evaluating `1 + 2` we do *not* apply this 
rule since neither of the operands is a string.  So that evaluates to
`3`, and then the evaluation of `3 + "3"` again needs this rule, and
hence yields `"33"`.


  -- Scott

[toc] | [prev] | [standalone]

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

csiph-web