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

Groups > comp.lang.javascript > #34309 > unrolled thread

get average height in an object

Back to article view | Back to comp.lang.javascript

Contents

  get average height in an object JRough <janis.rough@gmail.com> - 2017-11-11 14:57 -0800
    Re: get average height in an object Joao Rodrigues <groups_jr-1@yahoo.com> - 2017-11-12 06:04 -0200
      Re: get average height in an object Joao Rodrigues <groups_jr-1@yahoo.com> - 2017-11-12 06:49 -0200
      Re: get average height in an object John G Harris <niam@jghnorth.org.uk.invalid> - 2017-11-12 13:39 +0000
      Re: get average height in an object Joao Rodrigues <groups_jr-1@yahoo.com> - 2017-11-12 13:40 -0200
        Re: get average height in an object JRough <janis.rough@gmail.com> - 2017-11-13 12:06 -0800
        Re: get average height in an object Joao Rodrigues <groups_jr-1@yahoo.com> - 2017-11-15 13:14 -0200
          Re: get average height in an object "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-11-15 22:21 +0100
            Re: get average height in an object "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-11-15 22:57 +0100
              Re: get average height in an object Joao Rodrigues <groups_jr-1@yahoo.com> - 2017-11-16 02:46 -0200
                Re: get average height in an object "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-11-17 13:06 +0100
      Re: get average height in an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-11-12 18:24 +0100
        Re: get average height in an object Joao Rodrigues <groups_jr-1@yahoo.com> - 2017-11-13 00:26 -0200
          Re: get average height in an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-11-13 03:42 +0100
            Re: get average height in an object Joao Rodrigues <groups_jr-1@yahoo.com> - 2017-11-13 01:23 -0200
              Re: get average height in an object Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-11-13 14:16 +0100
                Re: get average height in an object Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2017-11-13 14:20 -0300
                  Dictionary-like objects (was: get average height in an object) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-11-13 19:56 +0100
                    Re: Dictionary-like objects Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2017-11-13 20:26 -0200
                      Re: Dictionary-like objects Julio Di Egidio <julio@diegidio.name> - 2017-11-13 15:48 -0800
                      Re: Dictionary-like objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-11-15 02:55 +0100
                        Re: Dictionary-like objects Joao Rodrigues <groups_jr-1@yahoo.com> - 2017-11-15 12:30 -0200
                        Re: Dictionary-like objects John G Harris <niam@jghnorth.org.uk.invalid> - 2017-11-15 15:59 +0000
          Re: get average height in an object JRough <janis.rough@gmail.com> - 2017-11-13 12:08 -0800
        Re: get average height in an object John G Harris <niam@jghnorth.org.uk.invalid> - 2017-11-13 10:17 +0000
        Re: get average height in an object JRough <janis.rough@gmail.com> - 2017-11-13 12:07 -0800
    Re: get average height in an object "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-11-12 11:00 +0100
      Re: get average height in an object "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2017-11-12 11:15 +0100
      Re: get average height in an object JRough <janis.rough@gmail.com> - 2017-11-13 12:28 -0800

Page 1 of 2  [1] 2  Next page →

#34309 — get average height in an object

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);

[toc] | [next] | [standalone]

#34312

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

As a side note there are better JS linters such as ESLint and JSHint.

> 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 = { /* ... */ };

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

The result

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

It lacks a semicolon after the "}".

> 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);
> 

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

[1] <http://www.jslint.com/help.html>
[2] 
<https://stackoverflow.com/questions/41539249/when-is-hasownproperty-not-required>

-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#34313

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

[toc] | [prev] | [next] | [standalone]

#34318

On Sun, 12 Nov 2017 06:04:42 -0200, Joao Rodrigues
<groups_jr-1@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

[toc] | [prev] | [next] | [standalone]

#34320

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

[toc] | [prev] | [next] | [standalone]

#34338

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.

[toc] | [prev] | [next] | [standalone]

#34359

Em 12/11/2017 13:40, Joao Rodrigues escreveu:
> Joao Rodrigues wrote:
> 
> 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
> 

I forgot to mention Object.values() [1], besides Object.entries [2]:

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

[1] 
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/values>
[2] 
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/entries>

-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#34361

Joao Rodrigues <groups_jr-1@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 }
};




-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#34363

"Evertjan." <exxjxw.hannivoort@inter.nl.net> wrote on 15 Nov 2017 in 
comp.lang.javascript:

> Joao Rodrigues <groups_jr-1@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);



-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#34365

Evertjan wrote:

> 
>> Joao Rodrigues <groups_jr-1@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

[toc] | [prev] | [next] | [standalone]

#34368

Joao Rodrigues <groups_jr-1@yahoo.com> wrote on 16 Nov 2017 in 
comp.lang.javascript:

> Evertjan wrote:
>> [..]
> 
> My mistake! Thanks for spotting the errors!
> [..]

Just playing with the concept by
not using the accumulator and not declaring the array:

const data = {
   "Matt" : { "height" : 174, "weight": 69 },
   "Jason" : { "height" : 190, "weight": 103 },
   "John" : { "height" : 80, "weight": 83 }
};

let res = {'avheight':0,'avweight':0};

Object.values(data).reduce(
	(x, v, n) => {
		res.avheight = (res.avheight*n + v.height)/(n+1);
		res.avweight = (res.avweight*n + v.weight)/(n+1);
		
	//	console.log('step number:', n);
	//	console.log('intermediate average height:', res.avheight);
	//	console.log('intermediate average weight:', res.avweight);
	}, 0);

console.log('final average height:',res.avheight);
console.log('final average weight:',res.avweight);


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#34322

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.

[toc] | [prev] | [next] | [standalone]

#34329

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

[toc] | [prev] | [next] | [standalone]

#34331

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.

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

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

This is a *specification* mechanism only.
 
> <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.

> 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.  But because the *script engine* inserts them anyway
according to the *language specification*, the *source code* *does*
work.  Which you would have known if you had actually tried it out.
 
>>>> 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.

Your claim was at least misleading.  It is _not_ the source code that 
requires an explicit semicolon there, but an error/warning-free *JSLint* 
parsing of that source code.  Big difference.

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

> However, you have *intentionally* omitted the fact that the for...in loop
> statement iterates over enumerable properties of an Object,

The for-in loop is *irrelevant* to your claim about the object and
my counter-argument demonstrating that it is false.

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

And that is simply wrong.  *You cannot know* what enumerable properties it 
has.  And it is certainly not a “dictionary-like object” if its prototype 
chain is not empty.

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

FOAD.

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

[toc] | [prev] | [next] | [standalone]

#34333

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, (2) an obsolete and opinionated linter such as JSLint. 
Anyway it's up to the OP to decide what to do. I was only commenting 
about the specific OP's problem regarding JSLint. You are missing the 
point again.

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

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

>   
>> "§ 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.
> 
> This is a *specification* mechanism only.
>   
>> <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.

> 
>> 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. And how did you get that idea? Read again the OP's 
question and my reply, because you have missed the point altogether.

>>>>> 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.
> 
> Your claim was at least misleading.  It is _not_ the source code that
> requires an explicit semicolon there, but an error/warning-free *JSLint*
> parsing of that source code.  Big difference.

I haven't claimed that the code would either require a semicolon or fail 
because of a missing semicolon. You are the only one claiming such a 
fallacy. I was just indicating the position in the OP's source code 
where JSLint complained about the missing semicolon. Period.

> 
>>>> 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"?! Your logic is flawed.


-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#34335

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.

[toc] | [prev] | [next] | [standalone]

#34336

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

[toc] | [prev] | [next] | [standalone]

#34337 — Dictionary-like objects (was: get average height in an object)

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

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

[toc] | [prev] | [next] | [standalone]

#34342 — Re: Dictionary-like objects

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

[toc] | [prev] | [next] | [standalone]

#34343 — Re: Dictionary-like objects

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web