From: The Natural Philosopher on
kangax wrote:
> Garrett Smith wrote:
>
> [...]
>
>> Perhaps future revisions of ECMAScript will include stronger wording for
>> Host objects, so that implementations will have at least some
>> conformance guidelines, though it seems too late for WebIDL, which
>> also takes liberty to implement special behavior on Host object,
>> defining a very large number of additional internal properties.
>
> ES5 (currently draft) puts few restrictions on host objects that weren't
> there in ES3. This makes for a somewhat saner state of affairs. `typeof`
> should now return more consistent results: "function" for any callable
> object — native *or host*; and anything but "undefined", boolean",
> "number" or "string" for host object that's not callable (doesn't
> implement [[Call]]).
>
> [[Class]] values of host objects are now more or less under control. To
> cite 8.6.2:
>
> "The value of the [[Class]] internal property of a host object may be
> any String value except one of "Arguments", "Array", "Boolean", "Date",
> "Error", "Function", "JSON", "Math", "Number", "Object", "RegExp", and
> "String"."
>
A software engineer is someone who does NOT spend two weeks arguing the
finer details of a language, or what a software engineer is.

HE rewrites in code so simple, there is nothing to argue about.

From: John G Harris on
On Wed, 18 Nov 2009 at 09:59:58, in comp.lang.javascript, The Natural
Philosopher wrote:

<snip>
>A software engineer is someone who does NOT spend two weeks arguing the
>finer details of a language, or what a software engineer is.
>
>HE rewrites in code so simple, there is nothing to argue about.

"if that's too dull for you, the door is over there ->" he said : he's a
manager. Unfortunately there are many managers who used to be engineers
who pontificate about what it is to be an engineer.

John
--
John Harris
From: Garrett Smith on
John G Harris wrote:
> On Wed, 18 Nov 2009 at 09:59:58, in comp.lang.javascript, The Natural
> Philosopher wrote:
>
> <snip>
>> A software engineer is someone who does NOT spend two weeks arguing the
>> finer details of a language, or what a software engineer is.
>>

comp.lang.javascript is the correct place to discuss how the language
works. That happens to be important to people who use the language.

Understanding a problem and how to solve it is a fundamental skill for
a software engineer.

This NG discusses mainly problems related to scripting HTML pages in a
browser. This particularl eg of this thread is centered around
discussion of type checking, where it is useful, where an abstraction
is useful, where it fails, what the specifications state.

Realize that c.l.js is an unmoderated NG; flippant remarks can and do
create disruption.

>> HE rewrites in code so simple, there is nothing to argue about.
>
> "if that's too dull for you, the door is over there ->" he said : he's a
> manager. Unfortunately there are many managers who used to be engineers
> who pontificate about what it is to be an engineer.
>
What he has described as his "management" techniques sound like not very
good characteristics for a manager (or code quality, or pride, or
healthy working relationships).
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: The Natural Philosopher on
Garrett Smith wrote:
> John G Harris wrote:
>> On Wed, 18 Nov 2009 at 09:59:58, in comp.lang.javascript, The Natural
>> Philosopher wrote:
>>
>> <snip>
>>> A software engineer is someone who does NOT spend two weeks arguing the
>>> finer details of a language, or what a software engineer is.
>>>
>
> comp.lang.javascript is the correct place to discuss how the language
> works. That happens to be important to people who use the language.
>
> Understanding a problem and how to solve it is a fundamental skill for
> a software engineer.
>
> This NG discusses mainly problems related to scripting HTML pages in a
> browser. This particularl eg of this thread is centered around
> discussion of type checking, where it is useful, where an abstraction
> is useful, where it fails, what the specifications state.
>
> Realize that c.l.js is an unmoderated NG; flippant remarks can and do
> create disruption.
>
>>> HE rewrites in code so simple, there is nothing to argue about.
>>
>> "if that's too dull for you, the door is over there ->" he said : he's a
>> manager. Unfortunately there are many managers who used to be engineers
>> who pontificate about what it is to be an engineer.
>>
> What he has described as his "management" techniques sound like not very
> good characteristics for a manager (or code quality, or pride, or
> healthy working relationships).

Believe me, I had to fire that guy. The only guy I ever had to fire.

My staff begged me to do it. He completely destroyed the morale of
people working damned hard to tight deadlines.


It transpired that he was actually writing a science fiction fantasy
online with a bunch on internet geeks. Writing plain code was just too
boring.
From: Thomas 'PointedEars' Lahn on
Garrett Smith wrote:

> Richard Cornford wrote:
>> Garrett Smith wrote:
>>> The eval call, as used there, has potential to modify variables
>>> in the calling context's scope chain. Using new Function or
>>> a call to eval in global context and scope avoids that. ES5
>>> would "fix" that:
>>>
>>> | 10.4.2: In Edition 5, indirect calls to the eval function use
>>> | the global environment as both the variable environment and
>>> | lexical environment for the eval code. In Edition 3, the
>>> | variable and lexical environments of the caller of an indirect
>>> | eval was used as the environments for the eval code.
>>>
>>> That would be a significant change, but one that would be of
>>> use to jQuery here.
>>
>> It would be of use to anyone who wanted to dynamically import script
>> source text. It is a pity that much of the dynamic importing of script
>> source text that goes on at present is already largely inadvisable.
>
> Importing script source text is possible by assigning a property to a
> globally-accessible identifier. Given an |items| object:
>
> "if(typeof items !== 'undefined') {"
> + "items.myNewItem = { name : 'a' };"
> +"}";
>
> What is inadvisable?

1. There is no `items' object. There is, at most, a property with
that name that stores a reference to an object.
2. What does this have to do with importing "script source text"?
Would you not want to use source code in a template in the same
context in which you included it, as in other languages? The
global meaning should be optional.
3. The spacing. `if' is not a function.
4. The assignment, if `items' refers to a host object.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>