is there a way in which i can get "magic" and "more magic" as the
output, without having to add super to the child class's constructor? I
was thinking about overriding the class method "new" but i really didn't
get anything to work up to now.
class Parent
def initialize
print "magic\n"
end
end
class Child < Parent
def initialize
super
print "more magic\n"
end
end
child = Child.new
···
On Mar 15, 2010, at 9:13 AM, Andrea Dallera wrote:
Hi everybody,
given the following situation:
class Parent
def initialize
print "magic\n"
end
end
class Child < Parent
def initialize
print "more magic\n"
end
end
child = Child.new
is there a way in which i can get "magic" and "more magic" as the
output, without having to add super to the child class's constructor? I
was thinking about overriding the class method "new" but i really didn't
get anything to work up to now.
that's exactly what i was trying to avoid. While I'm at it, let me be
more specific about my problem, which is actually not just printing out
text to the console but changing the state of the newly created
instance:
class Parent
attr_reader :test_value
def initialize @test_value = "from parent"
end
end
class Child < Parent
def initialize
p @test_value
end
end
child = Child.new
this should print out "from parent"
···
--
Andrea Dallera
On Mon, 2010-03-15 at 23:32 +0900, Chuck Remes wrote:
On Mar 15, 2010, at 9:13 AM, Andrea Dallera wrote:
> Hi everybody,
>
> given the following situation:
>
> class Parent
>
> def initialize
> print "magic\n"
> end
>
> end
>
> class Child < Parent
>
> def initialize
> print "more magic\n"
> end
>
> end
>
> child = Child.new
>
> is there a way in which i can get "magic" and "more magic" as the
> output, without having to add super to the child class's constructor? I
> was thinking about overriding the class method "new" but i really didn't
> get anything to work up to now.
Use the #super keyword to call the superclass.
class Parent
def initialize
print "magic\n"
end
end
class Child < Parent
def initialize
super
print "more magic\n"
end
end
On Mon, Mar 15, 2010 at 2:41 PM, Andrea Dallera <andrea@andreadallera.com>wrote:
Hei Chuck,
that's exactly what i was trying to avoid. While I'm at it, let me
be
more specific about my problem, which is actually not just printing out
text to the console but changing the state of the newly created
instance:
On Mon, 2010-03-15 at 23:32 +0900, Chuck Remes wrote:
> On Mar 15, 2010, at 9:13 AM, Andrea Dallera wrote:
> > Hi everybody,
> >
> > given the following situation:
> >
> > class Parent
> >
> > def initialize
> > print "magic\n"
> > end
> >
> > end
> >
> > class Child < Parent
> >
> > def initialize
> > print "more magic\n"
> > end
> >
> > end
> >
> > child = Child.new
> >
> > is there a way in which i can get "magic" and "more magic" as the
> > output, without having to add super to the child class's constructor? I
> > was thinking about overriding the class method "new" but i really
didn't
> > get anything to work up to now.
>
> Use the #super keyword to call the superclass.
>
>
> class Parent
> def initialize
> print "magic\n"
> end
> end
>
> class Child < Parent
> def initialize
> super
> print "more magic\n"
> end
> end
>
> child = Child.new
>
> ----------
>
> cremes$ ruby a.rb
> magic
> more magic
>
> cr
>
>
Ah, I didn't read your original email very closely.
I don't know how to accomplish that without #super. There might be a way to modify the parent's meta class and then have the child pick up that value, but I'm not really sure how to do it.
cr
···
On Mar 15, 2010, at 9:41 AM, Andrea Dallera wrote:
Hei Chuck,
that's exactly what i was trying to avoid. While I'm at it, let me be
more specific about my problem, which is actually not just printing out
text to the console but changing the state of the newly created
instance:
One way to avoid it is to override new. You can use the "allocate" method
to create a new object instance without invoking its constructor. Name the
superclass's "initialize" method something different, like preinitialize,
and invoke that yourself. Be sure to invoke initialize too, if it's
defined.
I've used this approach in frameworks where I intend for users to subclass,
but my general impression nowadays is I should use a lot cleaner base class
that doesn't need these sorts of hax, or not expect users to ever define
their own constructor.
···
On Mon, Mar 15, 2010 at 7:41 AM, Andrea Dallera <andrea@andreadallera.com>wrote:
On Mar 15, 2010, at 9:41 AM, Andrea Dallera wrote:
Hei Chuck,
that's exactly what i was trying to avoid. While I'm at it, let me be
more specific about my problem, which is actually not just printing out
text to the console but changing the state of the newly created
instance:
Andrea:
I think something similar was brought up on this mailing
list/forum/newsgroup within the last two weeks or so. Take a look
through the older topics.
--
Posted via http://www.ruby-forum.com/\.
what i don't like is that if you want to make _your_ viewmodel do stuff
on initialize, which is usual, you have to write your initialize method
as such:
def initialize
super #your stuff here
end
otherwise the automagical initialization (like building views, hooking
to services, etc) doesn't work, because the constructor of
FreightViewModel (that is the one taking care of all this) doesn't get
called.
I know this is not extremely important (you just have to remind to call
super) but i'd prefer not to have that hassle : i forget it myself more
than often.
···
--
Andrea Dallera
On Mon, 2010-03-15 at 23:50 +0900, Marvin Gülker wrote:
Andrea Dallera wrote:
> this should print out "from parent"
Maybe I can't follow you, but that's exactly what's super for:
-------------------------------------------
irb(main):001:0> class Parent
irb(main):002:1> attr_reader :test_value
irb(main):003:1> def initialize
irb(main):004:2> @test_value = "from parent"
irb(main):005:2> end
irb(main):006:1> end
=> nil
irb(main):007:0> class Child < Parent
irb(main):008:1> def initialize
irb(main):009:2> super
irb(main):010:2> p @test_value
irb(main):011:2> end
irb(main):012:1> end
=> nil
irb(main):013:0> child = Child.new
"from parent"
=> #<Child:0x0000000183c140 @test_value="from parent">
irb(main):014:0>
-------------------------------------------
Why don't you want it?
I like Tony's final suggestion. In your base class initialize method, have it make a call to post_initialize. All subclasses should then create a post_initialize method if they need to do any construction (or leave it empty).
This technique is used in Eventmachine since its internals like to control when and how classes are instantiated.
cr
···
On Mar 15, 2010, at 12:07 PM, Tony Arcieri wrote:
On Mon, Mar 15, 2010 at 7:41 AM, Andrea Dallera <andrea@andreadallera.com>wrote:
Hei Chuck,
that's exactly what i was trying to avoid.
One way to avoid it is to override new. You can use the "allocate" method
to create a new object instance without invoking its constructor. Name the
superclass's "initialize" method something different, like preinitialize,
and invoke that yourself. Be sure to invoke initialize too, if it's
defined.
I've used this approach in frameworks where I intend for users to subclass,
but my general impression nowadays is I should use a lot cleaner base class
that doesn't need these sorts of hax, or not expect users to ever define
their own constructor.
I'm sorry, I looked before posting and i couldn't find anything. I'm
looking now too and still I can't find it, so if you maybe have a
pointer to that it would be really nice. Sorry for spamming.
···
--
Andrea Dallera
On Tue, 2010-03-16 at 00:02 +0900, Aldric Giacomoni wrote:
Chuck Remes wrote:
> On Mar 15, 2010, at 9:41 AM, Andrea Dallera wrote:
>
>> Hei Chuck,
>>
>> that's exactly what i was trying to avoid. While I'm at it, let me be
>> more specific about my problem, which is actually not just printing out
>> text to the console but changing the state of the newly created
>> instance:
>>
>
Andrea:
I think something similar was brought up on this mailing
list/forum/newsgroup within the last two weeks or so. Take a look
through the older topics.
I am uncertain about what to do: on one side I'm very aware that it
would be a huge hack and, before all, using this kind of "template
method" in the base class, and having every element to inherit from it,
is very unflexible. On the other side i've been using freightrain for
quite a while now and i really really like the syntactic sugar, so
things like
MyFactory.getInstance() do
# user defines their behavior here
end
as Walton (which i thank for the pointer) suggested are a big no no.
I like this way of doing it:
def new(*a,&b)
obj = allocate #do your stuff
obj.send(:initialize,*a,&b)
return obj
end
What do you think about it? Aside from the performance hit (in my case i really don't case), are there any motivation i'm not seeing for not using it?
Also forbidding to specify the constructor would be a way to go but i'd like to allow as much freedom as possible.
···
--
Andrea Dallera
On Tue, 2010-03-16 at 02:24 +0900, Chuck Remes wrote:
On Mar 15, 2010, at 12:07 PM, Tony Arcieri wrote:
> On Mon, Mar 15, 2010 at 7:41 AM, Andrea Dallera <andrea@andreadallera.com>wrote:
>
>> Hei Chuck,
>>
>> that's exactly what i was trying to avoid.
>
>
> One way to avoid it is to override new. You can use the "allocate" method
> to create a new object instance without invoking its constructor. Name the
> superclass's "initialize" method something different, like preinitialize,
> and invoke that yourself. Be sure to invoke initialize too, if it's
> defined.
>
> I've used this approach in frameworks where I intend for users to subclass,
> but my general impression nowadays is I should use a lot cleaner base class
> that doesn't need these sorts of hax, or not expect users to ever define
> their own constructor.
I like Tony's final suggestion. In your base class initialize method, have it make a call to post_initialize. All subclasses should then create a post_initialize method if they need to do any construction (or leave it empty).
This technique is used in Eventmachine since its internals like to control when and how classes are instantiated.
FreightViewModel is part of the framework, and if you're using it that's
the way you should do it:
class MyViewModel < FreightViewModel
...
end
what i don't like is that if you want to make _your_ viewmodel do stuff
on initialize, which is usual, you have to write your initialize method
as such:
def initialize
super #your stuff here
end
otherwise the automagical initialization (like building views, hooking
to services, etc) doesn't work, because the constructor of
FreightViewModel (that is the one taking care of all this) doesn't get
called.
I know this is not extremely important (you just have to remind to call
super) but i'd prefer not to have that hassle : i forget it myself more
than often.
You ought to just get in the habit of remembering it.
Maybe you can write some kind of automatic checker that will look for
definitions of initialize that don't call super.
I think it's always appropriate to call super in an initialize call,
because everything descends from Object, and Object defines an initialize
method.
--Ken
···
On Tue, 16 Mar 2010 00:04:59 +0900, Andrea Dallera wrote:
--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology. http://www.iit.edu/~kbloom1/
I suppose you could change a bit the design and use a hook method
instead of initialize in the subclass. I mean, in the superclass you do
all your automagical initalization, then you call a (blank) hook method,
and later you redefine it when you build the new class. Something like
this:
class Parent
def initalize
# do automagic stuff
configure
end
def configure
# just a blank hook method
end
end
class Child < Parent
def configure
# do some specific stuff
end
end
···
Andrea Dallera <andrea@andreadallera.com> wrote:
what i don't like is that if you want to make _your_ viewmodel do stuff
on initialize, which is usual, you have to write your initialize method
as such:
def initialize
super #your stuff here
end
--
MySQL and PHP are popular not because of their quality, but despite it.
Found it: Is there a way to get a method to always run at the end of any descendent's initialize method? - Ruby - Ruby-Forum
While it does offer some methods you might use, I highly recommend not
trying to solve the problem this way. 'super' is an expected part of
sub-classing, and there may be instances in which the sub-classer does
*not* want your initializer to run. If this is something you need to
do, I might be inclined to solve it with the factory approach. So
instead those using your framework would do something like:
MyFactory.getInstance() do
# user defines their behavior here
end
which returns an already initialized object.
···
On 3/15/2010 9:11 AM, Andrea Dallera wrote:
I'm sorry, I looked before posting and i couldn't find anything. I'm
looking now too and still I can't find it, so if you maybe have a
pointer to that it would be really nice. Sorry for spamming.
I assume that '#do your stuff' is where you do things like call the
parents initializer?
1) What happens is the programmer *does* call super in initialize.
While sometimes it's ok for code to get run twice, sometimes it's not.
Be sure that if you are ensuring the parent class's initialize method
runs, that it doesn't foobar something if it runs twice because the user
called 'super'.
2) Are you sure there isn't an instance where someone would want to
subclass your class, but not run the parents initializer? One example
where I can think of this occurring is doing mocks for unit testing. I
may still want to use some of the functionality from your class (thus
subclassing it), but cut out some of the backing guts and replace them
with something I have control over.
Provided you have thought about those two things, and still think this
is the right choice, then I see no problem with this code.
···
On 3/15/2010 12:48 PM, Andrea Dallera wrote:
Hei,
I am uncertain about what to do: on one side I'm very aware that it
would be a huge hack and, before all, using this kind of "template
method" in the base class, and having every element to inherit from it,
is very unflexible. On the other side i've been using freightrain for
quite a while now and i really really like the syntactic sugar, so
things like
MyFactory.getInstance() do
# user defines their behavior here
end
as Walton (which i thank for the pointer) suggested are a big no no.
I like this way of doing it:
def new(*a,&b)
obj = allocate #do your stuff
obj.send(:initialize,*a,&b)
return obj
end
What do you think about it? Aside from the performance hit (in my case i really don't case), are there any motivation i'm not seeing for not using it?
Also forbidding to specify the constructor would be a way to go but i'd like to allow as much freedom as possible.
I agree: calling super is the default method for making sure super
classes are initialized properly. I would stick to that rather than
inventing some magic behind the scenes. For exampl, if you override #new to do what OP wants (which is possible) measures should be taken
to not break if someone actually invokes super in their #initialize.
Kind regards
robert
···
2010/3/15 Walton Hoops <walton@vyper.hopto.org>:
On 3/15/2010 9:11 AM, Andrea Dallera wrote:
I'm sorry, I looked before posting and i couldn't find anything. I'm
looking now too and still I can't find it, so if you maybe have a
pointer to that it would be really nice. Sorry for spamming.
Found it: Is there a way to get a method to always run at the end of any descendent's initialize method? - Ruby - Ruby-Forum
While it does offer some methods you might use, I highly recommend not
trying to solve the problem this way. 'super' is an expected part of
sub-classing, and there may be instances in which the sub-classer does
*not* want your initializer to run. If this is something you need to
do, I might be inclined to solve it with the factory approach. So
instead those using your framework would do something like:
MyFactory.getInstance() do
# user defines their behavior here
end
What happens is the programmer *does* call super in initialize.
While sometimes it's ok for code to get run twice, sometimes it's not.
Be sure that if you are ensuring the parent class's initialize method
runs, that it doesn't foobar something if it runs twice because the user
called 'super'.
Calling super shouldn't be a problem in this case: the constructor of the base class does nothing...right?
Are you sure there isn't an instance where someone would want to
subclass your class, but not run the parents initializer? One example
where I can think of this occurring is doing mocks for unit testing. I
may still want to use some of the functionality from your class (thus
subclassing it), but cut out some of the backing guts and replace them
with something I have control over.
Good point. I'm taking care of this, in a way that provides a full stub
(with all the dependencies stubbed and injected) for integration testing
with one line of code, which was one of the initial objectives: i come
from WPF and it can be a pain to write integration testing for a VM with
even just 3 services, i wanted to be able to test without having to
write huge and complex setups all the time. Still, one can think of
other cases where a VM is is still needed "uninitialized": i guess i'll
provide an hard switch if the case actually arises.
Thanks a lot for all the suggestions!
···
--
Andrea Dallera
On Tue, 2010-03-16 at 04:14 +0900, Walton Hoops wrote:
On 3/15/2010 12:48 PM, Andrea Dallera wrote:
> Hei,
>
> I am uncertain about what to do: on one side I'm very aware that it
> would be a huge hack and, before all, using this kind of "template
> method" in the base class, and having every element to inherit from it,
> is very unflexible. On the other side i've been using freightrain for
> quite a while now and i really really like the syntactic sugar, so
> things like
> MyFactory.getInstance() do
> # user defines their behavior here
> end
> as Walton (which i thank for the pointer) suggested are a big no no.
>
> I like this way of doing it:
> def new(*a,&b)
> obj = allocate
> #do your stuff
> obj.send(:initialize,*a,&b)
> return obj
> end
>
> What do you think about it? Aside from the performance hit (in my case i really don't case), are there any motivation i'm not seeing for not using it?
> Also forbidding to specify the constructor would be a way to go but i'd like to allow as much freedom as possible.
>
>
I assume that '#do your stuff' is where you do things like call the
parents initializer?
1) What happens is the programmer *does* call super in initialize.
While sometimes it's ok for code to get run twice, sometimes it's not.
Be sure that if you are ensuring the parent class's initialize method
runs, that it doesn't foobar something if it runs twice because the user
called 'super'.
2) Are you sure there isn't an instance where someone would want to
subclass your class, but not run the parents initializer? One example
where I can think of this occurring is doing mocks for unit testing. I
may still want to use some of the functionality from your class (thus
subclassing it), but cut out some of the backing guts and replace them
with something I have control over.
Provided you have thought about those two things, and still think this
is the right choice, then I see no problem with this code.
What happens is the programmer *does* call super in initialize.
While sometimes it's ok for code to get run twice, sometimes it's not.
Be sure that if you are ensuring the parent class's initialize method
runs, that it doesn't foobar something if it runs twice because the user
called 'super'.
Calling super shouldn't be a problem in this case: the constructor of the base class does nothing...right?
Right, so not an issue in this case.
Are you sure there isn't an instance where someone would want to
subclass your class, but not run the parents initializer? One example
where I can think of this occurring is doing mocks for unit testing. I
may still want to use some of the functionality from your class (thus
subclassing it), but cut out some of the backing guts and replace them
with something I have control over.
Good point. I'm taking care of this, in a way that provides a full stub
(with all the dependencies stubbed and injected) for integration testing
with one line of code, which was one of the initial objectives: i come
from WPF and it can be a pain to write integration testing for a VM with
even just 3 services, i wanted to be able to test without having to
write huge and complex setups all the time. Still, one can think of
other cases where a VM is is still needed "uninitialized": i guess i'll
provide an hard switch if the case actually arises.
Thanks a lot for all the suggestions!
Sounds to me like you've given it plenty of thought and are good to go.
Best of luck with your project!