Re: get average height in an object

[Joao Rodrigues]

Joao Rodrigues wrote:
> JRough wrote:
<snip>
>
>> and it says it needs a semi colon after the data  object?
>
> Sure does. A semicolon is required in the end of a statement.
>
> const data = { /* ... */ };
>

A correction here: const is a declaration.

Although JS engines would automatically insert the missing semicolon
into the source code token stream, it is better to not rely on the
Automatic Semicolon Insertion (ASI) rules.

See:
<http://www.ecma-international.org/ecma-262/6.0/#sec-automatic-semicolon-insertion>

--
Joao Rodrigues

[John G Harris]

On Sun, 12 Nov 2017 06:04:42 -0200, Joao Rodrigues
<group...@yahoo.com> wrote:

<snip>

>A semicolon is required in the end of a statement.

<snip>

... but not at the end of *every* statement.

An unnecessary semicolon is parsed as an Empty Statement and is
usually harmless. But in some cases it can cause trouble, as in

if (a)
{ do_this(); } ; /* Note semicolon! */
else
{ do_that(); }

John

[John G Harris]

On Sun, 12 Nov 2017 18:24:27 +0100, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

<snip>
>The value of the “data” constant *variable* here is a reference to an Object
>instance
<snip>

When an object is assigned to a property or variable there will be a
pointer of some kind involved. The question is this : Is that pointer
inside or outside the Value of the property or variable?

The Java specification says clearly [1] that the pointer is inside the
Value.

The ECMAScript standard says clearly [2] that the pointer is outside
the Value.

It is therefore totally incorrect when talking about ECMAScript to say
that
"The value ... is a reference to an Object instance".


[1] The Java Language Specification, Java SE 8 Edition, sec 4.3.1
[2] ECMA 262, v8, sec 6.1

John

[Thomas 'PointedEars' Lahn]

Joao Rodrigues wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Joao Rodrigues wrote:

>>> Thomas 'PointedEars' Lahn wrote:
>>>> Joao Rodrigues wrote:
>>>>> JRough wrote:

>>>>>> This seems like it should be easy enough but I don't get any error
>>>>>> messages in the console. I used jslint and it objects to the
>>>>>> console.log lines
>>>>> This happens because "console" is a browser (and Node.js) feature.
>>>>> However, you may use the /*global*/ directive to "hide" the error in
>>>>> JSLint [1]. For instance:
>>>>> /*global console */
>>>> Too sweeping, unless we are talking about a dedicated debug library.
>>> Useless remark since I wrote about a JSLint warning. It has nothing to
>>> do with libraries whatsoever. Don't miss the point.
>> *You* are missing the point. If you annotate the code as such, then
>> *all* uses of console.log() will be ignored. This is potentially
>> *detrimental* to code quality.
>
> 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. *In the right places*, console.log() can be and *is* *very
useful* even in production code.

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.

> Anyway it's up to the OP to decide what to do. I was only commenting
> about the specific OP's problem regarding JSLint.

In doing so, however, you have made claims about the programming language
and about its objects which are provably false.

>>>>> As a side note there are better JS linters such as ESLint and JSHint.
>>>> JSHint (which I prefer) will also warn about the undeclared use of
>>>> console.log().
>>> 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.

>>>>>> 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.

>>> <http://www.ecma-international.org/ecma-262/6.0/#sec-automatic-semicolon-insertion>
>>> 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.

>>> Look up the Standard and you will not find the term "optional" for
>>> semicolons.
>>> ECMAScript Language Specification 101.
>> You have claimed that *source code* would _not_ *work* if it had no
>> semicolons.
>
> No, I haven't.

Yes, you have. You did it *again* when you referred to the language
specification in that way, which is completely irrelevant here, so you
cannot talk your way out of it now.

>>>>> You don't really need to check for data.hasOwnProperty(key) in this
>>>>> case, because data is a simple dictionary-like object [2].
>>>> Nonsense, and your source does not corroborate your claim.

>>>>
>>>> The value of the “data” constant *variable* here is a reference to an

>>>> Object instance which inherits properties from the object referred to
>>>> by the initial value of Object.prototype
>>> Prototypal inheritance is a known concept by everyone here.
>> Not to you, obviously.
>
> Why "obviously"?!

const data = {
"foo": "bar",
"baz": "bla"
};

/* "function" */
console.log(typeof data["toString"]);

/* "function" */
console.log(typeof data["valueOf"]);

/* "object" (in some implementations) */
console.log(typeof data["__proto__"]);

A “dictionary-like object” (this was the term that *you* used) simply
does _not_ behave in that way.

Subsequently, I have elaborated on how such an object can actually be
created. You called that “drivel”.

> Your logic is flawed.

No, yours is.

--
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.

[Joao Rodrigues]

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.

> *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.

Anyway, putting console.log() in source code is insane and unnecessary,
given all modern browsers provide "DevTools" way more capable to debug
code nowadays.

>
> 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.

>
>> Anyway it's up to the OP to decide what to do. I was only commenting
>> about the specific OP's problem regarding JSLint.
>
> In doing so, however, you have made claims about the programming language
> and about its objects which are provably false.
>
>>>>>> As a side note there are better JS linters such as ESLint and JSHint.
>>>>> JSHint (which I prefer) will also warn about the undeclared use of
>>>>> console.log().
>>>> 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?

>
>>>>>>> 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.

>
>>>> <http://www.ecma-international.org/ecma-262/6.0/#sec-automatic-semicolon-insertion>
>>>> 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.

>
> Subsequently, I have elaborated on how such an object can actually be
> created. You called that “drivel”.
>
>> Your logic is flawed.
>
> No, yours is.
>

You are trying to shift the burden of proof.

--
Joao Rodrigues

[Thomas 'PointedEars' Lahn]

Joao Rodrigues wrote:

> 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?

>>>>> <http://www.ecma-international.org/ecma-262/6.0/#sec-automatic-semicolon-insertion>
>>>>> 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

[JRough]

On Sunday, November 12, 2017 at 7:40:14 AM UTC-8, Joao Rodrigues wrote:
> Joao Rodrigues wrote:
>

> > I've refactored the OP's code to:
> >
> > const data = {
> >   "Matt" : {  "height" : 174, "weight": 69 },
> >   "Jason" : { "height" : 190, "weight": 103 }
> > };
> >
> > function calcAvgHeight(data) {
> >   var count = 0, sumHeight = 0;
> >   for (var key in data) {
> >     sumHeight += data[key].height;
> >     count += 1;
> >   }
> >   return sumHeight/count;
> > }
> >
> > console.log(calcAvgHeight(data)); // 182

> >
> > You don't really need to check for data.hasOwnProperty(key) in this
> > case, because data is a simple dictionary-like object [2].
> >
>

> Another solution using Object.keys and Arrow functions:
>
> let arr = Object.keys(data);
> let getHeight = key => data[key]["height"];
> let avg = arr.reduce((a,c) => getHeight(a) + getHeight(c)) / arr.length;
> console.log(avg); // 182
>
> Or using Object.entries() from ES2017:
>
> let heights = Object.entries(data).map(el => el[1].height);
> let avg2 = heights.reduce((a,c) => a + c) / heights.length;
> console.log(avg2); // 182
>
> --
> Joao Rodrigues

thanks, first one is very easy to understand the keys and objects iteration. Second one is more elegant. IT works.

[JRough]

On Sunday, November 12, 2017 at 9:24:34 AM UTC-8, Thomas 'PointedEars' Lahn wrote:
> Joao Rodrigues wrote:
>

> > JRough wrote:
> >> This seems like it should be easy enough but I don't get any error
> >> messages in the console. I used jslint and it objects to the console.log
> >> lines
> >
> > This happens because "console" is a browser (and Node.js) feature.
> > However, you may use the /*global*/ directive to "hide" the error in
> > JSLint [1]. For instance:
> >
> > /*global console */
>
> Too sweeping, unless we are talking about a dedicated debug library.
>

> > As a side note there are better JS linters such as ESLint and JSHint.
>
> JSHint (which I prefer) will also warn about the undeclared use of
> console.log().
>

> With JSHint at least, it is then better to annotate the corresponding
> statement only so as to suppress the *warning* temporarily –
>
> <http://jshint.com/docs/#inline-configuration>
>
> – and to not leave any *unintended* debug statements in *production* code.
>
> <http://jshint.com/docs/options/#globals> p.
> <http://jshint.com/docs/options/#undef>
> <http://jshint.com/docs/options/#devel>
> <http://jshint.com/docs/options/#node>

>
> >> 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. ECMAScript implementations insert semicolons
> automatically according to the grammar. However, because that can have
> unintentional results, and because of readability, writing semicolons
> explicitly is *recommended*, considered good code style (and should be
> contained in any style manual).
>
> That would be taught in “JavaScript 101”.
>
> > The result

> >>
> >> const data = {
> >> "Matt" : { "height" : 174, "weight": 69 },
> >> "Jason" : { "height" : 190, "weight": 103 }
> >> }
> >

> > It lacks a semicolon after the "}".
>
> Nonsense:
>
> | -> const data = {

> | "Matt" : { "height" : 174, "weight": 69 },
> | "Jason" : { "height" : 190, "weight": 103 }
> | }

> | <- undefined
> |
> | -> data
> | <- Object {Matt: Object, Jason: Object}

>
> > I've refactored the OP's code to:
> >
> > const data = {
> > "Matt" : { "height" : 174, "weight": 69 },
> > "Jason" : { "height" : 190, "weight": 103 }
> > };
> >
> > function calcAvgHeight(data) {
> > var count = 0, sumHeight = 0;
> > for (var key in data) {
> > sumHeight += data[key].height;
> > count += 1;
> > }
> > return sumHeight/count;
> > }
> >
> > console.log(calcAvgHeight(data)); // 182
>

> And unsurprisingly this compiles and executes without any semicolons and
> quote characters as well.

>
> > You don't really need to check for data.hasOwnProperty(key) in this
> > case, because data is a simple dictionary-like object [2].
>

> Nonsense, and your source does not corroborate your claim.
>
> The value of the “data” constant *variable* here is a reference to an Object
> instance which inherits properties from the object referred to by the

> initial value of Object.prototype:
>
> | -> const o = {};
> | <- undefined
> |
> | -> typeof o.toString
> | <- "function"
> |
> | -> o.foo = "bar"
> | <- "bar"
> |
> | -> o
> | <- Object {foo: "bar"}
> |
> | -> o = 42
> | <- |> Uncaught TypeError: Assignment to constant variable. VM1150:1
> ^^^^^^^^
> | at <anonymous>:1:3
>
> (That, too, would be taught in “JavaScript 101”.)
>
> IOW, that a value has been assigned to an identifier that has been declared
> with “const” does *not* in general mean that the data referred to by the
> identifier cannot change. It means that the identifier cannot be assigned
> to *again*, so *only* if its value is *primitive* it cannot be changed.
>
> In order to create a true “dictionary-like object”, one has to use
>
> var o = Object.create(null, …);
>
> or
>
> const o = Object.create(null, …);
>
> or equivalent [see jsx.object.getDataObject() in my JSX:object.js and, more
> recently, jsx.object.createDataObject()¹ in the same file].
>
> In order to create immutable objects, one also needs to use Object.seal() or
> Object.freeze() or equivalent.
>
> <http://www.ecma-international.org/ecma-262/8.0/#sec-properties-of-the-object-constructor>
>
> > [2]
> > <https://stackoverflow.com/questions/41539249/when-is-hasownproperty-not-required>
>
> Next time, try it out before you post.
>
> ______
> ¹ The method is not a getter but a factory, hence the renaming; by using
> function references, the older identifier remains an alias until I have
> refactored all the code that uses it.

> --
> 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.

thanks for the JShint links. I switched to that one.

[JRough]

On Sunday, November 12, 2017 at 6:26:24 PM UTC-8, Joao Rodrigues wrote:
> Thomas 'PointedEars' Lahn wrote:
> > Joao Rodrigues wrote:
> >
> >> JRough wrote:
> >>> This seems like it should be easy enough but I don't get any error
> >>> messages in the console. I used jslint and it objects to the console.log
> >>> lines
> >>
> >> This happens because "console" is a browser (and Node.js) feature.
> >> However, you may use the /*global*/ directive to "hide" the error in
> >> JSLint [1]. For instance:
> >>
> >> /*global console */
> >
> > Too sweeping, unless we are talking about a dedicated debug library.
>

> Useless remark since I wrote about a JSLint warning. It has nothing to
> do with libraries whatsoever. Don't miss the point.
>
> >

> >> As a side note there are better JS linters such as ESLint and JSHint.
> >
> > JSHint (which I prefer) will also warn about the undeclared use of
> > console.log().
>

> Of course ESLint, JSHint and JSLint warn about undeclared use of
> 'console' and its methods. JS Linters 101.
>
> >

> >>> 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:
>

> "§ 11.9 - Automatic Semicolon Insertion
> Certain ECMAScript statements (empty statement, let, const, import, and
> export declarations, variable statement, expression statement, debugger
> statement, continue statement, break statement, return statement, and
> throw statement) *must be terminated with semicolons*."
>
> Notice the *must be terminated with semicolons* sentence.

>
> <http://www.ecma-international.org/ecma-262/6.0/#sec-automatic-semicolon-insertion>
>
> Omitting semicolons does not mean they are optional in the Language.

> Look up the Standard and you will not find the term "optional" for
> semicolons.
>
> ECMAScript Language Specification 101.
>
> >>>

> >>> const data = {
> >>> "Matt" : { "height" : 174, "weight": 69 },
> >>> "Jason" : { "height" : 190, "weight": 103 }
> >>> }
> >>
> >> It lacks a semicolon after the "}".
>

> I was pointing out the position in the OP's source text where they
> reported the JSLint warning. So the comment above is valid in the
> context of the OP's question. You are missing the point.

>
> >
> >> I've refactored the OP's code to:
> >>
> >> const data = {
> >> "Matt" : { "height" : 174, "weight": 69 },
> >> "Jason" : { "height" : 190, "weight": 103 }
> >> };
> >>
> >> function calcAvgHeight(data) {
> >> var count = 0, sumHeight = 0;
> >> for (var key in data) {
> >> sumHeight += data[key].height;
> >> count += 1;
> >> }
> >> return sumHeight/count;
> >> }
> >>
> >> console.log(calcAvgHeight(data)); // 182
> >
> > And unsurprisingly this compiles and executes without any semicolons and
> > quote characters as well.
>

> It sure does. You are missing the point again.

>
> >
> >> You don't really need to check for data.hasOwnProperty(key) in this
> >> case, because data is a simple dictionary-like object [2].
> >
> > Nonsense, and your source does not corroborate your claim.
> >
> > The value of the “data” constant *variable* here is a reference to an Object
> > instance which inherits properties from the object referred to by the
> > initial value of Object.prototype
>

> Prototypal inheritance is a known concept by everyone here. However, you
> have *intentionally* omitted the fact that the for...in loop statement
> iterates over enumerable properties of an Object, and that's precisely
> the point here: the hasOwnProperty method is irrelevant for iterating
> the Object referenced by the "data" constant because it hasn't got
> enumerable properties inherited from Object in the OP's example.

>
>
> >
> > | -> const o = {};
> > | <- undefined
> > |
> > | -> typeof o.toString
> > | <- "function"
> > |
> > | -> o.foo = "bar"
> > | <- "bar"
> > |
> > | -> o
> > | <- Object {foo: "bar"}
> > |
> > | -> o = 42
> > | <- |> Uncaught TypeError: Assignment to constant variable. VM1150:1
> > ^^^^^^^^
>

> You are missing the point again and again.

>
> >
> > Next time, try it out before you post.
> >
>

> Next time, read carefully the OP and subsequent answers before posting
> drivel.
>
> --
> Joao Rodrigues

to get around changing the lint preferences you can do window.console.log and it resolves.

[JRough]

On Sunday, November 12, 2017 at 2:00:41 AM UTC-8, Evertjan. wrote:
> JRough <janis...@gmail.com> wrote on 11 Nov 2017 in
> comp.lang.javascript:

>
> > This seems like it should be easy enough but I don't get any error
> > messages in the console. I used jslint and it objects to the

> > console.log lines and it says it needs a semi colon after the data
> > object? In any case, maybe I did something wrong with the second for
> > loop where I am only trying to collect the height property. I am not
> > exactly sure how to get the height property from the data object. The
> > result of running this script is undefined. thanks,

> >
> > const data ={
> > "Matt" : { "height" : 174, "weight": 69 },
> > "Jason" : { "height" : 190, "weight": 103 }
> >}
> > function calcAvgHeight(data) {

> > "use strict";
> > var count = '';
> > var avgHeight = '';
> > var result = [];

> > for (var key in data){

> > if (!data.hasOwnProperty(key)){
> > return;
> > }
> > var obj = data[key];
> > for (var height in obj){
> > if(!obj.hasOwnProperty.height){
> > return;
> > }
> >
> > console.log(obj[height]);
> > result.push(obj[height]);
> > count += 1;
> > avgHeight = result/count;
> > console.log(avgHeight);
> > return avgHeight ;
> > }
> > }
> >}
> > calcAvgHeight(data);
> >
>
> <script>
> 'use strict';
> let total = 0, numb = 0;

> const data = {
> "Matt" : { "height" : 174, "weight": 69 },
> "Jason" : { "height" : 190, "weight": 103 }

> };
>
> Object.keys(data).forEach(
> (key) => {
> numb++;
> total += data[key]['height'];
> }
> );
>
> console.log('total height = ' + total,
> ', number of heights = ' + numb,
> ', average height = ' + total/numb);
>
> </script>
>
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

thanks, nice use of foreach and arrow functions.

[Joao Rodrigues]

Thomas 'PointedEars' Lahn wrote:
> Joao Rodrigues wrote:
>
>> 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.

Logical conclusion? You must be kidding! You are the King of Fallacies
in Usenet. I have yet to see someone who can beat you in this respect.

>
>>> *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.

That might be considered a fallacy roughly speaking, but not a
"by-the-book /ad hominem/ argument", because I was not denigrating your
image when I said that you worked alone or did not use a version control
system. However, you interpreted that as an attack to your image.
Anyway, I just don't care.

>
> Also, why do you make up things and pretend that they are true?

You do that *all the time* - only you don't recognize the fact.

> GitHub is
> _not_ a version control system (Git, which GitHub uses, is).

Don't say.

> And your claim
> that I would not use such is so *obviously* false

> – read my sigs.

FYI, no one cares about them.

>
>> 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.

Maybe a little wrong, not dead wrong.

>
> Sometimes it is still necessary to use console.log() for debugging because
> the interaction with the built-in debugger causes unwanted results.

I challenge you to give an example of that.

>
> 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.

In debug code, yes. However, using console.log() in production code is
pure nonsense.

>
>>> 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.

Don't say.

>>>
>>> Annotating “console” as an implicit global for the whole file, as you
>>> suggested, *counteracts* this benefit. (Except, AISB, if it is a *debug*
>>> library.)

You are picking my comment regarding the OP's question and putting it in
an wide context. What is the name for this fallacy?

>>>
>>>> (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.

You are missing the point. JSLint is opinionated and everyone knows
about that, except (maybe) his creator. But you are trying to distort my
words conveniently in favour of your arguments.

>
> [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.]
>

You do that *all the time*.

> 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*.

My suggestion for using the JSLint global directive would affect only
the file in which it appears - the OP's example. Nonetheless, you are
trying to spread panic around such a trivial fact as if it was the end
of the world.

>>>>> 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?

Again, one can observe your customary behaviour in using /ad hominem/
fallacy against everyone that "dares" to thwart your arguments.

>
> Here is another one:
>
> /* somewhere in code that the OP’s code uses */
> Object.prototype.answer = 42;

Extending Object.prototype is generally a bad idea, but extending it
with enumerable properties is even worse. I would never expect that from
you. And you are changing my words, putting them in a different context,
just to prove your point.

I had enough. Bye.


--
Joao Rodrigues

[Julio Di Egidio]

On Monday, November 13, 2017 at 11:26:56 PM UTC+1, Joao Rodrigues wrote:
> Thomas 'PointedEars' Lahn wrote:

<snip>

> > 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.
>
> In debug code, yes. However, using console.log() in production code is
> pure nonsense.

Your distinction between debug code and production code is nonsense. As
long as it "works", logging to the console is just fine. *Of course* with
the system growing one moves from console.log to myLogger.log, but that's
about systems growing *organically*, not about console.log being right or
wrong in itself. Yes, do just use console.log as far as it is convenient.

> >>>> (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.
>
> You are missing the point. JSLint is opinionated and everyone knows
> about that, except (maybe) his creator. But you are trying to distort my
> words conveniently in favour of your arguments.

But his point is perfectly fine: *every* linting tool is in that sense
"opinionated", on the other hand *every* decent linting tool lets you
configure your own rules, you aren't stuck with the defaults: so just
fix your own linting profile and there you have your own rules. IOW,
your criticism here is simply misplaced.

> You do that *all the time*.

He is some kind of a picky jerk (IMO, anyway no heavy offence meant, it's
more my poor English), sometimes wasting a lot of time on quite unimportant
details at the expense of actual substance, on the other hand the guy does
know his stuff, so take the good: there are really few people in the entire
world who still know what programming is even about...

HTH,

Julio

[Thomas 'PointedEars' Lahn]

Joao Rodrigues wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Also, why do you make up things and pretend that they are true?
>
> You do that *all the time* - only you don't recognize the fact.
>
>> GitHub is _not_ a version control system (Git, which GitHub uses, is).
>
> Don't say.
>
>> And your claim that I would not use such is so *obviously* false
>
>> – read my sigs.
>
> FYI, no one cares about them.

How could you possibly know?

If you would care about them, you would not need to make up spurious claims
about me. My sig has been saying for a long time that I am using SVN, and
more recently that I am providing Git repositories hosted on GitHub, too.
From that it is evident that I am contributing to free software projects of
others as well. And, not to put too fine a point on it, it also says that I
am the maintainer of the FAQ for comp.lang.javascript and the author of the
ECMAScript Support Matrix.

You appear to have no clue whom you are talking about (or to).

>>> 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.
>
> Maybe a little wrong, not dead wrong.

Wrong again.

>> Sometimes it is still necessary to use console.log() for debugging
>> because the interaction with the built-in debugger causes unwanted
>> results.
>
> I challenge you to give an example of that.

Debugging keyboard and mouse events.

>> 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.
>
> In debug code, yes. However, using console.log() in production code is
> pure nonsense.

It is not. People do it all the time, for the *right* reasons. You have no

clue what you are talking about.

>>>> Annotating “console” as an implicit global for the whole file, as you
>>>> suggested, *counteracts* this benefit. (Except, AISB, if it is a
>>>> *debug* library.)
>
> You are picking my comment regarding the OP's question and putting it in
> an wide context. What is the name for this fallacy?

It is not a fallacy. Your knee-jerk suggestion is unwise at best. As I
indicated, the logical course of action, *if* JSLint is actually a problem,
is to use something like JSHint, to use console.log() only in the right
places, and then use JSHint & Co.’s refined annotation. Even the OP seem
to have realized that.

>>>>> (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.
>
> You are missing the point. JSLint is opinionated and everyone knows
> about that,

Especially the silent majority which agrees with you :->

<https://en.wikipedia.org/wiki/Argumentum_ad_populum>

> except (maybe) his creator. But you are trying to distort my words
> conveniently in favour of your arguments.

Your logic is flawed. That JSLint may be “opinionated” on certain points
does not change the fact that it is a good idea to point out the unintended
use of “console” and other environment-specific global symbols.

>> [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.]
>
> You do that *all the time*.

Liar. The record shows that I am the first to admit when I have been
*showed* to be wrong.

>> 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*.
>
> My suggestion for using the JSLint global directive would affect only
> the file in which it appears - the OP's example. Nonetheless, you are
> trying to spread panic around such a trivial fact as if it was the end
> of the world.

Nonsense. You do not know the full content of the OP’s file.

>>> That was hilarious indeed.
>> It was. Your overconfident ignorance is most refreshing at times.
>> Have you ever heard of the Dunning–Kruger effect?
>
> Again, one can observe your customary behaviour in using /ad hominem/
> fallacy against everyone that "dares" to thwart your arguments.

<https://en.wikipedia.org/wiki/Dunning–Kruger_effect>

>> Here is another one:
>>
>> /* somewhere in code that the OP’s code uses */
>> Object.prototype.answer = 42;
>
> Extending Object.prototype is generally a bad idea, but extending it
> with enumerable properties is even worse. I would never expect that from
> you.

Straw man. You really need to read more carefully.

> I had enough. Bye.

“I am out of arguments but I am afraid to admit it.”

[Joao Rodrigues]

Thomas 'PointedEars' Lahn wrote:

>>> It was. Your overconfident ignorance is most refreshing at times.
>>> Have you ever heard of the Dunning–Kruger effect?
>>
>> Again, one can observe your customary behaviour in using /ad hominem/
>> fallacy against everyone that "dares" to thwart your arguments.
>
> <https://en.wikipedia.org/wiki/Dunning–Kruger_effect>

I am happy that you have been searching for help in Wikipedia.

>
>>> Here is another one:
>>>
>>> /* somewhere in code that the OP’s code uses */
>>> Object.prototype.answer = 42;
>>
>> Extending Object.prototype is generally a bad idea, but extending it
>> with enumerable properties is even worse. I would never expect that from
>> you.
>
> Straw man. You really need to read more carefully.

I agree with you on the hasOwnProperty() check within for...in loops, if
it makes you feel good.

>> I had enough. Bye.
>
> “I am out of arguments but I am afraid to admit it.”
>

No, I am just bored to death with you rambling on and on.

--
Joao Rodrigues

[John G Harris]

On Wed, 15 Nov 2017 02:55:50 +0100, Thomas 'PointedEars' Lahn
<Point...@web.de> wrote:

<snip>

>Liar. The record shows that I am the first to admit when I have been
>*showed* to be wrong.

<snip>

Untrue.

John

[Joao Rodrigues]

Evertjan wrote:

>
>> Joao Rodrigues <group...@yahoo.com> wrote on 15 Nov 2017 in
>> comp.lang.javascript:

>>
>>> const data = {
>>> "Matt" : { "height" : 174, "weight": 69 },
>>> "Jason" : { "height" : 190, "weight": 103 }

>>> };
>>>
>>> let arr = Object.values(data);
>>> let avg = arr.reduce((a,c) => a.height + c.height) / arr.length;
>>> console.log(avg); // 182
>>
>> This will fail for:

>>
>> const data = {
>> "Matt" : { "height" : 174, "weight": 69 },

>> "Jason" : { "height" : 190, "weight": 103 },
>> "John" : { "height" : 80, "weight": 83 }
>> }; >
> So try this:
>
> let arr = Object.values(data);
> let avg = arr.reduce((r, v) => {
> return r + v.height;
> }, 0) / arr.length;
> console.log('average: ' + avg);
>
>
> and if you want to see what is going on in the reduce():
>
> let arr = Object.values(data);
> let avg = arr.reduce((r, v) => {
> console.log(r, r + v.height);
> return r + v.height;
> }, 0) / arr.length;
> console.log('average: ' + avg);
>

My mistake! Thanks for spotting the errors!

According to MDN [1], the reduce() method will execute the callback
function in different ways depending on the existence of the optional
initialValue argument.

As I didn't provide an initialValue of 0, I should have returned an
Object for the next iteration within reduce(). For instance:

var arr = Object.values(data);
var sum = (prev, cur) => ({height: prev.height + cur.height});
var avg = arr.reduce(sum).height / arr.length;
console.log(avg); // 148

And providing an initialValue of 0 as you did, reduce() will work
differently:

var arr = Object.values(data);
var sum = (accumulator, obj) => accumulator + obj.height;
var avg = arr.reduce(sum, 0) / arr.length;
console.log(avg); // 148

<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce>


--
Joao Rodrigues