On 5/27/07, Robert Klemme wrote:
> Erwin, are you aware of delegate?

Yes, but it's not transparent as I'd like. I don't want the delegating
class to answer methods like class and is_a? for example. It also
doesn't work when trying to distinguish the class with a case
construct.

On 27.05.2007 07:04, Morton Goldberg wrote:
> What I see when I evaluate your code is:
>
>    x.class # => String
>    x.size  # => 14

My mistake, I had an array to begin with and didn't remember to change
the results to match when I changed it to a string.

> A better solution would be to use the second form of "case" to have more
> control over the test
>
> case
>    when Array == x.class
>    when String == x.class
> end

That's not bad. I like it... and it's a little more explicit, too. I
didn't know you could use case that way, that seems pretty useful.

> Viewing this more abstract: maybe case isn't even the right thing to do.
>   We would have to know more about what the OP is trying to accomplish.

Well the idea is to wrap an object with this proxy class and not mess
up any code that doesn't know about it... it should seem completely
transparent. It gives you a separate namespace for methods and
instance variables, so you don't have to worry about redefining those
with a mixin or singleton method, but you can still specialize some
object by wrapping it.

> I think using case statements to distinguish the class of an object is
> kind of ugly under any circumstances.

I think it works pretty well, but I'd like to know what you prefer
instead. I realize distinguishing objects by class is not encouraged,
but I find myself needing it often, for better or worse.

> On an even more general level there is a certain contradiction between
> having something behave exactly like an Array - but also different... :-)

Yes, that's a good observation.  Though I'm very happy with how close
I've gotten to making it happen.