Path: csiph.com!feeder.erje.net!2.eu.feeder.erje.net!news.mb-net.net!open-news-network.org!.POSTED.214.226.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Dictionary-like objects (was: get average height in an object) Date: Mon, 13 Nov 2017 19:56:35 +0100 Organization: PointedEars Software (PES) Lines: 191 Message-ID: <19625708.EfDdHjke4D@PointedEars.de> References: <4335673.31r3eYUQgx@PointedEars.de> <2901334.aeNJFYEL58@PointedEars.de> <1735928.PYKUYFuaPT@PointedEars.de> 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="214.226.197.178.dynamic.wless.zhbmb00p-cgnat.res.cust.swisscom.ch:178.197.226.214"; logging-data="930"; mail-complaints-to="abuse@open-news-network.org" User-Agent: KNode/4.14.2 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-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. Thomas 'PointedEars' Lahn wrote: >> Joao Rodrigues wrote: >>> I doubt an experienced developer would use: (1) console.log() in >>> production code, >> Which shows that, at the very least, you are not an experienced developer >> yourself. > > /Ad hominem/ fallacy - the one you like to use most of the time. No, it is a logical conclusion. >> *In the right places*, console.log() can be and *is* *very >> useful* even in production code. > > "Different strokes for different folks". Keep using console.log() in > production code as you wish. If you really do what you preach, that's > because you work alone or do not use version control systems such as > GitHub. Now *that* is a by-the-book /ad hominem/ argument. Also, why do you make up things and pretend that they are true? GitHub is _not_ a version control system (Git, which GitHub uses, is). And your claim that I would not use such is so *obviously* false – read my sigs. > Anyway, putting console.log() in source code is insane and unnecessary, > given all modern browsers provide "DevTools" way more capable to debug > code nowadays. You are dead wrong. Sometimes it is still necessary to use console.log() for debugging because the interaction with the built-in debugger causes unwanted results. Also, sometimes it is useful to have console.log() & friends in *some* places even if one is not actually debugging the code. For example, if you *want* to generate *messages* that only *developers* need to see. >> The very point of linters like JSLint is to make sure that it does not >> appear *unintentionally* in *production* code, as a remnant of debug >> code. >> >> Annotating “console” as an implicit global for the whole file, as you >> suggested, *counteracts* this benefit. (Except, AISB, if it is a *debug* >> library.) >> >>> (2) an obsolete and opinionated linter such as JSLint. >> >> The same is true for other linters *by default*, so that argument does >> not hold water. > > Nonsense. It is not nonsense. *For example*, JSHint will by default produce a warning on the use of “console”, too, because it does not need to be defined in order to be used; so that is not at all “opinionated” of JSLint. [If you want to remember, you had made that argument yourself; I am merely repeating it. Unfortunately, one can observe here again that you "forget" your own arguments when they become inconvenient for you.] However, maybe by contrast to JSLint, JSHint provides several ways in which to disable that warning in *some* places where the use of “console” was *intentional*. >>>>> Of course ESLint, JSHint and JSLint warn about undeclared use of >>>>> 'console' and its methods. JS Linters 101. >>>> That is simply untrue. As I have showed, it depends on the >>>> configuration. >>> The default configuration of all those linters will warn about the use >>> of console.log() (and missing semicolons where they are expected). >> But this is a fundamentally different statement than the one that you >> made before. > > How did you get that idea? That is *self-evident*. The second statement is more restrictive. >>>>>>>> and it says it needs a semi colon after the data object? >>>>>>> Sure does. A semicolon is required in the end of a statement. >>>>>> No, in general it is not. >>>>> Nonsense. If semicolons were really optional there would not be a >>>>> thing called "Automatic Semicolon Insertion" (ASI) in the >>>>> Specification, which states: >>>> You have no clue what you are talking about. >>> You too! >> LOL. > > That was hilarious indeed. It was. Your overconfident ignorance is most refreshing at times. Have you ever heard of the Dunning–Kruger effect? >>>>> >>>>> Omitting semicolons does not mean they are optional in the Language. >>>> Yes, it means exactly that. >>> It's obvious. >> Apparently you misunderstand my “Yes” to mean confirmation of your >> opinion when it means the exact opposite. > > Then I should say you have no clue what you are talking about. RTFM. There is no FM to read because none corroborates your claim. You have a misconception there. >>> Your logic is flawed. >> No, yours is. > > You are trying to shift the burden of proof. Not at all. I have provided the proof already, but you are ignoring (and not quoting) it. As if that would make it disappear and people would not remember. Here is another one: /* somewhere in code that the OP’s code uses */ Object.prototype.answer = 42; /* lots of LOCs */ /* OP’s code */ const data = { "foo": "bar", "baz": "bla" }; You have called what the right-hand side of the latter statement evaluates to a “dictionary-like object”. But when assuming the former statement *or something built-in to the same effect*, one finds: /* 42 */ console.log(data["answer"]); var keys = []; for (var name in data) { keys.push(name); } /* _at least_ ["answer", "foo", "baz"] */ keys A “dictionary-like object” simply does not behave like this. It would _not_ contain keys that have _not_ been added to it explicitly. This refutes your argument that the referred object would be such an object, and proves that you have not understood “prototypal inheritance” in ECMAScript (implementations). Not filtering for-in loops is unwise in *any* case, unless the prototype chain of the object iterated over is empty. (And even then there is the remote possibility that a built-in enumerable property exists.) As I indicated before, such an object can, for example, be created thus: const data = Object.assign(Object.create(null), { "foo": "bar", "baz": "bla" }); This is basically what const data = jsx.object.createDataObject({ "foo": "bar", "baz": "bla" }); does. /* * jsx.object.getKeys() basically does this, as does the native * Object.keys() now (JSX had it first) */ var keys = []; for (var name in data) { keys.push(name); } /* _virtually guaranteed_ ["foo", "baz"] */ keys -- PointedEars FAQ: | | Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.