On 12/24/10, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:
> On Dec 24, 3:05 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>
>> I rather have it one way or the other. e.g.
>>
>> makePoint(x, y);
>>
>> - OR -
>>
>> new Point(x, y);
>>
>> I just don't like seeing any extra if/else in the code. I also don't
>> want to handle the case where somebody might be relying on an anomaly
>> of calling the constructor as a function call.
>
> If defensive programming isn't necessary, of course. But since JS
> can't statically enforce such things it may be necessary to do so.
>
If a factory is used, then that's irrelevant. Toy example:
function getAPoint(x, y) {
}
The worst the client could do would be to use `new getAPoint`. That
would be a problem if the API expects `this` to be global object.
Methods can be shared in scope, but the x and y properties can be
instance properties.
function getAPoint(x, y) {
function distanceFromOrigin() {
return Math.sqrt((this.x * this.x) + (this.y * this.y));
}
getAPoint = function(x, y) {
return {
x : x,
y : y,
distanceFromOrigin: distanceFromOrigin
};
};
return getAPoint(x, y);
}
getAPoint(4, 0).distanceFromOrigin();
The downside to that is `distanceFromOrigin` is hanging off the VO, so
it looks like a private static method, so what is `this`?
It might be OK to "leak" a little implementation detail in this case:
function getAPoint(x, y) {
function Point(x, y) {
this.x = +x;
this.y = +y;
}
Point.prototype = {
distanceFromOrigin : function() {
return Math.sqrt((this.x * this.x) + (this.y * this.y));
}
};
getAPoint = function(x, y) {
return new Point(x, y);
};
return getAPoint(x, y);
}
The Point constructor is cached on the VO of the outer getAPoint.
Outer getAPoint identifier gets assigned to inner getAPoint identifier
but the scope chain of the inner getAPoint function has the Point
constructor and prototype.
>> > Plus when using the constructor pattern, Java style "super" calls can
>> > be emulated with apply()
>>
>> When Point has a superclass or when Point *is* the superclass?
>
> In general I mean vs the Object.create() pattern.
>
>> Generally I keep the constructors private and only use factories and
>> return an interface object. Doing that avoids having to deal with
>> constructor issues.
>
> Just seems like more boilerplate when building a hierarchy as you'd
> have to manually set the constructor property and fidget with
> prototypes to make instanceof and the constructor property work as
> expected. But I guess if its not expected to be used that way it
> wouldn't matter.
>
The client of the API gets an interface object that has properties and
methods so instanceof and constructor shouldn't matter.
--
Garrett
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/jsmentors@jsmentors.com/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/jsmentors@googlegroups.com/
To unsubscribe from this group, send email to
jsmentors+unsubscr...@googlegroups.com
