From: "Chr. Rippel" Date: 2002-01-27T22:14:06+09:00 Subject: Re: Subrange of String subclass => invalid object "Bob Alexander" wrote in .... > > class List < Array; end > > i = 0 > > L = List.new(5).collect!{ i+=1 } > > p L.type # => List > > p L.select {|i| i % 2 == 0 }.type # => Array > > p L.collect {|i| i*i }.type # => Array > > p L.collect! {|i| i*i }.type # => List > > ---- > > I don't think it is a bad thing if all of operations above to return > Lists -- after all Lists *are* Arrays. If Lists are proper subtypes of Array > you would never know the difference. Of course it should be well defined in > the subclass's interface what type it returns. My issue is not about > returning instances of the subclass so much as returning broken objects. > > > Anyway in your particular example it does not seem apparent > > if sub_indexing makes a copy of your instance variable or not - > > Viewing this at slightly higher level, one could assume that it should > return a non-broken object. If instance variables have to be initialized to > certain values to achieve that, then it should be so. Clearly it broke the > inspect method in my example. > Well borrowing from your reply to Matz post > 1. I received an object of the superclass type (String, in my example). > 2. I received a non-broken object of my subclass type. > Outcome (1) is natural and correct, but boring. > Outcome (2) might be impossible to do in the general case. Call me boring but I prefer (1) since (2) is impossible in the general case. The problem in my opinion is that the current String implementation preforms a hidden (and normally forbidden) #become operation - down casting a String object to an S object forgoing proper initialization - a good example is class HistoryString < String def initialize (str) super @orig_length = length end attr_reader :orig_length end Here a blind copying policy of instance variables is not going to do you any good because it would be wrong. I was pretty surprised that RCR 38 mostly went through because this problem is pretty apparent and introduces an IMO fairly useless feature unnecessarily complicating the language - the sort of thing Python advocates often criticize about Ruby. As it is we probably cannot do much about the current situation (besides back- paddling on RCR 38). Things would be somewhat different if Ruby would sport a general #become framework (which would probably would involve the call of a pre and post #become hook methods - a sort OO-equivalent of the real live process of a person going through a sex change) putting the unusual behavior of sub-classing from the String class in a more general and (using a Python slogan) explicit context. /Christoph /OT - Implementation issues aside - yes I do think #become might be a useful operation since it is does occur in nature, for example, some fish species commonly change gender, on the other hand the rats tail of social and legal consequences of a (human) sex change is probably a good indication for the resistance human thinking seem to harbor towards ``type'' change.