[suby-talk] Meta programming from without

TRANS transfire at gmail.com
Tue Sep 20 22:10:59 EDT 2005

Let me know if the return address problem is fixed. Thanks.

On 9/20/05, Peter Vanbroekhoven <calamitas at advalvas.be> wrote:
> Well, I guess the arguments against are as follows:
> * It's less OO-ey.

Or more, in the sense of being strict about good OOP practice.

> * Because of that, overriding the behavior of is_a? in the second case
>    would mean adding a layer over MP::is? (with aliasing, or cuts, or other
>    tricks), which seems rather awkward.

These methods one generally does not want to override --that would
entail some very extreme meta-programming.

> * These extra layers would slow things down.

That always a problem, isn't it? :-/

> It seems to me though that you only want to do this for methods that
> should not be overridden. I'm not sure that === is among them as it does
> general matching, not just for classes.

That's true. #=== would still remain, and perhaps for classes route it
through the MP (or whatever it would be called).

But yes, the idea is that there are methods that one wants to keep
"safe" as a matter of meta-programming. Currently the (minimal)
convention is to provide __ameth__ methods. But these give no
guarantee, and some methods aren't provided for (__class__ for
instance). In other cases #instance_ameth is used. Then there are the
few others --a new example, Matz is now thinking of adding #fcall.

> OTOH I understand your reason to do it, namely to keep Object as clean as
> possible method-wise. Well, that's what I understood from it --correct me
> if I'm wrong.

Keeping it clean is a nice side-effect. But the main reason is two
fold. 1) ensure the availability of meta-programming features.
Currently they are rather scattered about name-wise and can be too
easily overridden, even inadvertently. And 2) to keep with good OOP
practices. One of the reasons Matz uses long method names like
#instance_variable_get is simply to discourage usage b/c it is not
good OOP. I've always felt this approach bordering on silly.


More information about the suby-talk mailing list