Tom Gregory wrote:
I'd vote to have all Effects handled the same way. I don't care which
way, but they should be consistent.
I agree with consistency. Just wanted to insert my two cents on the
topic if anyone decides to make a patch:
1. I think the "new Effect.Blah()" is better over "Effect.Blah()"
because it allows for an object to maintain state if it chooses. Of
course not all objects will maintain state but if you are standardizing
the interface might as well allow the object to choose if state should
be maintained vs. letting the library choose for the object (and
tempting people to go back to an inconsistent method).
2. We should try to maintain backwards compatibility. I.E. so a patch
should allow "Effect.Fade()" and "new Effect.Fade()" to not break
compatibility. This should be achievable since in both cases we are
calling the same function. We just need to make sure that the function
is implemented so that it checks if it was called as a constructor
function or a regular function and if it is called as a regular function
it would call itself as a constructor function. Something like:
var Effect.Fade = function() {
if( this instanceof Effect.Fade )
this.initialize.apply(this, arguments)
else
return new Effect.Fade(arguments)
}
Not sure if the above would work exactly but that is the basic idea.
We could perhaps do this globally by changing the Class.create() method
to return an anonymous function which does this checking but I am not
really sure how that would be implemented.
Eric
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
