Path: csiph.com!weretis.net!feeder8.news.weretis.net!news.mb-net.net!open-news-network.org!.POSTED.172.228.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: JavaScript + DOM, type system Date: Sat, 21 Nov 2020 23:27:02 +0100 Organization: PointedEars Software (PES) Lines: 102 Message-ID: <5677746.lOV4Wx5bFT@PointedEars.de> References: <2K-dneuu4a7SySrCnZ2dnUU7-Q3NnZ2d@westnet.com.au> <76yi7wo8a7g1$.hlchiey5r3hb$.dlg@40tude.net> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit Injection-Info: gwaiyur.mb-net.net; posting-host="172.228.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch:178.197.228.172"; logging-data="20131"; mail-complaints-to="abuse@open-news-network.org" User-Agent: KNode/4.14.10 Cancel-Lock: sha1:iUhqasrwxOY3/NcAqa9vKRSAc8w= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEfy7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkkPbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5DOjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrmF2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTcIKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2EdLo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbCnPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYNrgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v/DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg== X-User-ID: U2FsdGVkX190JoysgUyJ5Ac0HPeiGwuvZQq8FC5m99TE2H6fx9z6FA== X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. 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, > 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, -- PointedEars FAQ: | | Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.