jslint doesn't like my syntax for conditional object creation

[Thomas 'PointedEars' Lahn]

[VK nonsense about pre-declaration]

this is why say

<script type="text/javascript">
if (foobar == null) {foobar = {};}

[errors]

It errors because in neither statement is foobar declared.

Full ACK.

I guess that, where foobar has not been declared, statements like:

function blah(){
foobar = 5;
}

create foobar as a global variable to provide a simple way of creating
globals from inside a function. [...]

No. This may read as me nitpicking again, but *still* _no_ /variable/
is created, but a property of the Global Object is (unless a superordered
execution context has a Variable Object with that property in which case
the property value changes). Either Brendan (Eich) had this in mind or he
did not care about the difference. However, since we know for some time
now that there is a scoping problem with the IE DOM, it is possible that
it may be elsewhere. Hence (and for the sake of transparent maintainable
code) this code style is considered harmful and recommended against. So
if you need an identifier, you better declare it.


PointedEars

 

[Thomas 'PointedEars' Lahn]

The interpreter has looked ahead and seen the entire code.

The _compiler_ has.


PointedEars

 

[Richard Cornford]

Better by what criteria?

In this case it is better because the structure of the objects in the
environment reflects a real relationship between the roles of those
objects. Which is why I would insist that - member - must be suited to
being a member or Circle. If it is not is should not be associated with
the Circle object at all, and so may be more appropriate being a global
function.

What makes it better?

Nothing makes it better as such. A sensible system of 1000 objects
would be expected to have, and so express, hierarchical relationships.
If no such relationships existed then there is no reason for there
being a hierarchical structure in the code.

I'm starting to think your reasons are programmer preference.
That is fine if it makes the code more maintainable for you.

My reasons are mostly that I like the structures used in javascript to
properly reflect the concepts being implemented. If being a method of a
constructor expresses the real relationship between the constructor
(the objects it constructs) and its method then it should be a property
of the constructor, else it should never be.

The namespace simulation idea proposed creating deep hierarchies of
object structures with no better reason for entire level existing in
that hierarchy than that namespaces are being simulated. That does not
strike me as a good reason for creating deep object structures, and the
justification that doing so avoids naming collisions is only convincing
to people who have seen the value of namespaces in languages with
enormous library/package collections and not seen that the issues
addressed there does not apply to a know, limited set of javascript
code intended to be downloaded to a web browser in its entirety.

Without a positive reason for simulating namespaces (no consequential
benefits) the performance degradation (no matter how small) only leaves
only a reason for not simulating namespaces.

However, not simulating namespaces because you only have a reason for
not doing so is not the same as not creating properties of constructors
because that suffers the same drawback as simulating namespaces. There
may be positive reasons for creating a property of a constructor that
outweigh the slight performance degradation of the extra lookup needed
to resolve the property accessor.

However if there is a perfomance bottleneck then I would
have no problem writing Circle_member rather than
Circle.member. I don't use underscore much in
JavaScript anyway so they both look the same to me.

It would be more of a performance degradation than a bottleneck. But
the best reason for deciding between Circle.member (or some other name)
and Circle.member when assigning a function is the relationship between
that function and Circle. The decision could go either way, depending
on the code.

Richard.

 

[Thomas 'PointedEars' Lahn]

What are the implications of this statement on the discussion of "Class
Methods" in JavaScript? In particular I am looking at page 126 of
JavaScript: The Definative Guide 4th ed. In the example, he has a class
called "Circle" and wants a class menthod called "max".

function Circle(radius){ stuff }
function Circle_max(a,b){ stuff }
Circle.max = Circle_max;

No, he has not! There are two Function objects with identifiers Circle and
Circle_max. The naming convention suggests that they are to be used as
constructors for an object. Then the first Function object is augmented
with a `max' property that becomes a method identifier because it is
assigned a reference to the second Function object (which subsequently can
be called as a method of the first Function object).

This example seems like a real mess. Why clutter the global namespace
with Circle_max?

Full ACK.

Maybe there is some other reason but given that we
probably will only ever call Circle.max we have two better options

Option 1 directly create a class method

You should stop thinking of client-side ECMAScript implementations in
terms of class-based object-oriented programming languages. Those are
prototype-based programming languages to date. The only production-level
ECMAScript (4) implementation that implements class-based programming
to date is JScript.NET, which is server-side only (and even if it was
client-side as well, it would be restricted to Microsoft applications).

function Circle(radius){ stuff }
Circle.max = function(a,b){ stuff };

This is a possibility, but not a reasonable one. For you will have only
one usable Circle object. If you use Circle as a constructor, the newly
created object --

var myCircle = new Circle(42);

-- will _not_ inherit the max() method, and you will have to

Circle.max.call(this, 42, 23);

and the like to affect the new object's properties. Therefore, you should
augment the constructor's prototype object instead:

function Circle(radius){ stuff }
Circle.prototype.max = function(a,b){ stuff };

Now you can create a new Circle object that will inherit the max() method
from the prototype object of the constructor through the prototype chain:

... myCircle.max(42, 23) ...

Option 2 use a function instead of a class method

Again, will you please recognize that there are no classes, hence no "class
method"s?

You will probably be better off burning Goodman's ... book, subscribing to
this newsgroup, and reading the ECMAScript Language Specification among
other reference material.


PointedEars

 

[John G Harris]

What are the implications of this statement on the discussion of "Class
Methods" in JavaScript? In particular I am looking at page 126 of
JavaScript: The Definative Guide 4th ed. In the example, he has a class
called "Circle" and wants a class menthod called "max".

function Circle(radius){ stuff }
function Circle_max(a,b){ stuff }
Circle.max = Circle_max;

This example seems like a real mess. Why clutter the global namespace
with Circle_max? Maybe there is some other reason but given that we
probably will only ever call Circle.max we have two better options

Option 1 directly create a class method

function Circle(radius){ stuff }
Circle.max = function(a,b){ stuff };

Earlier versions of javascript didn't have function expressions, alias
anonymous functions. E.g In NN 4. The book goes back a long way.

Besides, he might be explaining that methods can be attached to objects,
leaving function expressions until later. (I haven't got the book so I
don't know for sure.)

Option 2 use a function instead of a class method

function Circle(radius){ stuff }
function Circle_max(a,b){ stuff }

In some languages, like Java, Option 1 would allow Circle.max access to
class variables. I think that this is not really an issue in JavaScript
because nothing is private, true? However Option 1 will have slower
execution speed because the interpreter must resolve the '.' every time
we use Circle.max().

Global variables and global functions are also properties so they still
go through the '.' process even though you don't have to type the dot.

Are you sure that the first, implicit, dot in Circle.max is going to be
no slower than the second, explicit, dot ? How would you measure it ?

So we could/should just use Option 2 which doesn't have much namespace
collision possiblity anyway.

So what the heck was he arguing about when he said on page 126 that
"associating these function with a class gives them a convenient niche
in the JavaScript namespace and prevents namespace collisions." There
is no real benifit and a small perfomance decrease.

Well, the function name can be so long it's unlikely to collide with
another one. If you never have to use the name because you write
Circle.max it doesn't matter if it's called
PetersCircleClassVersion1Max.

Obviously, if you don't need to worry about older browsers you use
Option 1.

Is the objects chapter of this book getting worse the more I read it or
am I out to lunch here?

It's a popular text book : 'nuff said.

John