From: Erwin Abbott Date: 2007-05-27T22:23:46+09:00 Subject: Re: Tricky problem with === 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.