Back to the original question though: Why was it architected this
way? Is there a need to persist with dual implementations, or will a
patch to unify the syntax--at least for Effect--be accepted/welcomed?
I'd vote to have all Effects handled the same way. I don't care
which way, but they should be consistent.
TAG
On Jun 14, 2006, at 11:29 AM, Matt Spendlove wrote:
I've also been confused by this in the past so I thought I'd try
and qualify for myself and I think the explanation is fairly
straight forward...
It depends on whether the reference in question is expected to be a
standard JS Function (Object) or a specialised Object created by
Prototypes' Class.create().
Creating an object with Class.create() forces Prototype to call the
`initialize' method upon construction (mimicking Ruby syntax),
presumably to encapsulate state etc. You can still make reference
to the effect (e.g Effect.Opacity) without constructing the object
first but without initialisation you can't expect it to work. Be
nice if this was more consistent but that's the nature of the beast..
From the source code for examples you quoted ;
new Insertion.Before (...);
[ Insertion.Before = Class.create();]
new Effect.Opacity(...)
[Effect.Opacity = Class.create();]
Effect.Fade(..);
[Effect.Fade = function(element) {....}]
Effect.Appear(...);
[Effect.Appear = function(element) {...}]
So I guess, as you say, that latter are just static calls and the
former RELY upon state in object instantiation..
HTH
Matt
_______________________________________________
Rails-spinoffs mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
