From: "jonathan <zjll9@...> <zjll9@... <zjll9@" <zjll9@...>
Date: 2005-12-13T14:11:10+09:00
Subject: Re: About class methods

Eero Saynatkari wrote:
>> Why is the code above unadvisable?
> 
> I personally think the idiom is a bit suspect but it could
> just be I have not come across the need for it :) The above
> merely illustrates that it is quite possible to do that in
> ruby; however, another way might lead to a better design.
> 
> (Generally, any types of factories are simple in ruby and
> the whole duck-typing thing helps, too.)
>

I don't really see how duck-typing is relevant, but I would assume that 
the idiom used above (i.e., 'const_set', 'class_eval', and 
'define_method') could be done in an extension factory (rather than 
procedurally as above).  In other words, you might have a factory called 
JumpExtensionFactory which could create any object that can jump (e.g., 
people, animals, monsters, etc.) from a non-jumping object say in a 
video game model.

I suppose it would have to calculate the maximum jump height and length 
based on other statistics such as leg strength, weight, etc. (which 
would presumably have to be attributes the object already has or can 
acquire) and the actual jump height and length based on run-time 
attributes such as velocity and input force.  That is the purpose I can 
see for this sort of thing.  Is that what you mean by utilizing 
factories?

The only real problem I see with this is you really wouldn't want to 
create a new object, but rather extend the original one.  In other 
words, after a type learns to jump, then all objects of that type should 
be able to jump (so there's no need to distinguish from a non-jumping 
version and the jumping version).  So, actually, I would call it an 
JumpExtender or a JumpTeacher (instead of JumpExtensionFactory).

(Thinking out loud here).  But, hopefully we're closer to the same page 
now.

--J

-- 
Posted via http://www.ruby-forum.com/.