Re: Subrange of String subclass => invalid object

"Bob Alexander" <[e-mail]> 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.