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

Groups > comp.lang.javascript > #39168

Re: JavaScript + DOM, type system

Show all headers | View raw

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.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web