Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!news.albasani.net!weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: array-like objects Date: Tue, 05 Jan 2016 20:13:17 +0100 Organization: PointedEars Software (PES) Lines: 91 Message-ID: <2389107.ZQXF91zPQe@PointedEars.de> References: <39241641.QMrUfM43MS@PointedEars.de> <15615987.a6MfTLryX4@PointedEars.de> <4796632.tdeKqXnCYY@PointedEars.de> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1452021198 20411 eJwFwYEBwCAIA7CXANvKzhGY/59gwiVXb4gCL+/5jeDA5uzOlGW5hBzocKoA16wPvjoCjAcRtBA4 (5 Jan 2016 19:13:18 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Tue, 5 Jan 2016 19:13:18 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwNyccBwDAIBLCVMOXA41DM/iMk+soEB+0Kg9raVuLOFKbOg3A3r6erJkkGFvHKinT+8824VG3OGTVP2Yk/dD0V6g== Cancel-Lock: sha1:0rRo2qz7At5PvSRPJg8bHH7lX9Y= X-NNTP-Posting-Host: eJwNxdEVADEEBMCWzsOinHCr/xKSnxlXCCYMDvP1TRmZ89josP+LNhbfZ1nNEQ1oEiSyav0CLU0RqQ== Xref: csiph.com comp.lang.javascript:29150 John Harris wrote: > On Mon, 04 Jan 2016 15:27:13 +0100, Thomas 'PointedEars' Lahn > wrote: >> John Harris wrote: >>> On Sun, 03 Jan 2016 16:59:02 +0100, Thomas 'PointedEars' Lahn >>> wrote: >> Attribution *line*, _not_ attribution novel. > > Agent won't let me make it one line. I strongly doubt that your software is that b0rked that it would not allow you to edit that part of the posting before you submit it, if all else fails. > If you don't like it complain to Forte. Why should *I*? *You* would be the user using software intended for use with Usenet that is as far as is known inadequate to the task. So, short of stopping to post to Usenet, *you* can find out how to configure the software appropriately (there are newsgroups for that if the software manual does not suffice), work around its flaws (e.g., with MorVer; since it is unfree closed source software, you cannot edit and recompile the source code), edit the attribution before posting, switch to better software, or complain to the vendor. Since it is Forté Agent, and Forté *Free* Agent, you paid for the software, so you have a right to good product quality and it is *your* privilege and responsibility to exercise that right. Reasonably, my choice as one of your readers includes only to killfile you for not doing either of that, since *you* are making threads in which *you* participate harder to read. >>> The syntax says >>> identifier_b = identifier_a ; >>> The semantics are complicated. They say >>> If The storage area associated with identifier_a holds a >>> primitive (non-object) value >>> Then The storage area associated with identifier_b will now also >>> hold this primitive value, but a different instance of it >>> Else The object associated with identifier_a will now also be >>> associated with identifier_b >>> (Note : there are other ways of saying this) >> >>How did you get that idea? > > By reading ECMA 262. If you think that ECMA-262 (which Edition?) is confirming your ideas, then you will have no difficulty citing the corresponding algorithms and referring explicitly to the relevant parts. > Where don't you agree? I do not agree with your idea as a whole. Also, ECMAScript does not specify implementation behavior in such a detail as that would hinder the flexibility of implementations, so it is highly doubtful at best that you can substantiate your claim. In particular, for an implementation it is far easier to always copy the memory content on simple assignment, and have the memory content define what type of ECMAScript value is being stored. IOW, it stands to reason that object references are simply values and only treated specially in a property access. For example, although my C is a bit rusty, different to your idea, in C it makes a lot more sense to me to handle an ECMAScript value as one of a type struct with fields for the values of every built-in primitive type except String, one pointer field for String (since IIRC, strings in C of arbitrary length are implemented as pointers of char) and one for object types, the latter two pointing to an address in the heap where the memory area for the actual object value starts, and finally one field indicating the stored type (so that you know which of the value fields of the struct contains or refers to the stored value; I would define and use numeric constants for that). Then, when the identifier reference has been resolved to a value, you look at the type field of the struct and determine what to do if the identifier is the base of a property access (values of built-in primitive types need to be converted to values of corresponding built-in object types internally before property access is possible; or, maybe you can save more memory and runtime if you always treat values as objects to begin with – IIRC, someone here has posted their research on a major implementation to that effect). In any case, your newest attempt of trying to shift the burden of proof is unsuccessful. -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.