From: "Jan E." <lists@...>
Date: 2012-10-31T02:05:41+09:00
Subject: Re: Calling a method foo() or an object foo.method_call_here - both

Marc Heiler wrote in post #1082039:
> However I am not sure why you need to give your opinion
> here in regards to the problem description.

This is not my opionion in the sense of "I like red more than blue".
This is how I view the problem and what I would consider to solve it.
Unless you ask for e. g. the result of 1 + 1, there's no definite
solution. Everything we suggest is based on our personal experiences and
estimations. And that's exactly why I say "I think ...". It's called
honesty. ;-)

Considering a different language was a serious suggestion. Some people
simply don't adopt OOP and will always think procedurally. In this case
it *might* make sense to actually use a procedural language which
doesn't come with all the OOP baggage. I'm not telling you to dump Ruby,
I'm simply saying: If you rarely use the OOP features and mostly try to 
get rid of them, maybe it's just not the right language.

Anyway, the more I think about this, the more I'm sure that a template 
engine is what you want. What about Haml? http://haml.info/ This also 
has the big advantage of not being embedded into the Ruby code, so the 
templates are cleanly separated from the programming logic and easier to 
edit.

A more "hackish" solution could be to change the execution context of 
your Ruby methods so that they're evaluated with the prefixed class 
being "self" and don't need an explicit receiver (see 
instance_eval/class_eval/module_eval). Or you simply wrap the method 
calls in another method of the module. Then you don't even have to 
fumble with "self".

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