Rails spinoffs - Jun 2006 - why some features uses new and some just static function call

Hi,

when using prototype and scriptaculous, isn''t it confusing sometimes to
remember which ones you have to use new and which ones that are just static
function call.

For example:
new Insertion.Before(...);
new Effect.Opacity(...)

Effect.Fade(..);
Effect.Appear(...);

I havent really looked at the implementation, but out of curiosity, I''m
just
wondering is there a reason some of the function must instantiate new
object, most of the time you dont even use the object after instantiating
it. am I correct?

thanks,
- reynard


_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Hmm, I''m pretty sure they can all be used either way, since functions
are
first class objects (you can either invoke or instanstiate, and
instantiation also causes invocation of the constructor, which in this case
is also the meat and potatoes)...

I think instantiation of the Effects, et. al., depends on whether or not you
need a handle to it for some other purpose later, or maybe for
settings/memory re-use.

On 6/13/06, Reynard Hilman
<reynard.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Hi,
>
> when using prototype and scriptaculous, isn''t it confusing
sometimes to
> remember which ones you have to use new and which ones that are just static
> function call.
>
> For example:
> new Insertion.Before(...);
> new Effect.Opacity(...)
>
> Effect.Fade(..);
> Effect.Appear(...);
>
> I havent really looked at the implementation, but out of curiosity,
I''m
> just wondering is there a reason some of the function must instantiate new
> object, most of the time you dont even use the object after instantiating
> it. am I correct?
>
> thanks,
> - reynard
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
>
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Thanks for the explanation. The functions that require instantiation
won''t
work if you just call the function though.


Hmm, I''m pretty sure they can all be used either way, since functions
are
> first class objects (you can either invoke or instanstiate, and
> instantiation also causes invocation of the constructor, which in this
> case
> is also the meat and potatoes)...
>
> I think instantiation of the Effects, et. al., depends on whether or not
> you
> need a handle to it for some other purpose later, or maybe for
> settings/memory re-use.

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

Well then I guess I was wrong :-)

Just do what works and call it magic :-)

On 6/14/06, Reynard Hilman
<reynard.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Thanks for the explanation. The functions that require instantiation
won''t
> work if you just call the function though.
>
>
>
> Hmm, I''m pretty sure they can all be used either way, since
functions are
> > first class objects (you can either invoke or instanstiate, and
> > instantiation also causes invocation of the constructor, which in this
> > case
> > is also the meat and potatoes)...
> >
> > I think instantiation of the Effects, et. al., depends on whether or
not
> > you
> > need a handle to it for some other purpose later, or maybe for
> > settings/memory re-use.
>
>
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
>
>

_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs

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

Ryan Gahl wrote:
> Well then I guess I was wrong :-)
>
> Just do what works and call it magic :-)
>
> On 6/14/06, *Reynard Hilman* <
reynard.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> <mailto:reynard.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>>
wrote:
>
>     Thanks for the explanation. The functions that require
>     instantiation won''t work if you just call the function though.
>
>
>
>         Hmm, I''m pretty sure they can all be used either way,
since
>         functions are
>         first class objects (you can either invoke or instanstiate, and
>         instantiation also causes invocation of the constructor, which
>         in this case
>         is also the meat and potatoes)...
>
>         I think instantiation of the Effects, et. al., depends on
>         whether or not you
>         need a handle to it for some other purpose later, or maybe for
>         settings/memory re-use.
>
>
>
>     _______________________________________________
>     Rails-spinoffs mailing list
>     Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
>    
<mailto:Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org>
>     http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Rails-spinoffs mailing list
> Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
>

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

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