On Dec 24, 2010, at 6:43 PM, Garrett Smith wrote:
> On 12/24/10, Michael Haufe (TNO) <[email protected]> wrote:
>> On Dec 24, 3:05 pm, Garrett Smith <[email protected]> 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();
I would say that coding this way should not be done unless there is an extreme
requirement for it.
>
> 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);
> }
this should be done this way. you should not be defining the constructor
function every time you run your factory, this what is
really doing is creating a new constructor function every time and building an
instance for it completely useless because because
then how would you do instanceof? never put this type of closures for factories
unless really needed.
var Point = function(){};
var getAPoint = function(x,y){
return new Point(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/[email protected]/
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/[email protected]/
>
> To unsubscribe from this group, send email to
> [email protected]
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
