Re: Destructive type conversion (to_i!, to_f!)

Hi --

On Sun, 23 Nov 2003, Charles Comstock wrote:

> On Sun, 23 Nov 2003, David A. Black wrote:
> 
> > The built-in ! methods do in-place operations on the same object,
> > whereas the thing you're looking to do is to reassign the variable to
> > a different object.  So it's really taking place at a different
> > logical and/or semantic level.
> > 
> > However, I think there was discussion recently, and possibly in the
> > past also, of the idea of:
> > 
> >  obj .= method
> > 
> > which would be shorthand for
> > 
> >  obj = obj.method
> > 
> > That's more analogous to the
> > 
> >  obj += other
> > 
> > form, which is shorthand for
> > 
> >  obj = obj + other   # i.e., reassignment to variable, not in-place
> >                      # modification
> > 
> 
> Hmm, 
> 
> I'm not sure about .= as a syntax personally.  It makes sense in light of
> += and -= but symantically it seems weird with regard to objects since basically 
> it's an alternate form of .  Since . effectively means "send" what does .= mean 
> in that context?  It would be nice in terms of being short and sweet, but 
> not so nice in terms of symantics. 
> 
> I did think of the issue of not technically changing the existing object when 
> using a destructive type change.  The key issue of this is that I viewed it as a 
> type change and not a object reassignment.  Technically since the prevailing 
> view of ruby objects is the 'duck typing' model you should be able to change the 
> type of an object instead of reassigning.  By this I mean you should be able to 
> take a specific duck and turn it into a fish.  And then have it derive from 
> whatever classes fish derive from and no longer derive from whatever a duck 
> derives from.  So you ought to be able to extend an object and unextend an 
> object.  Or I may just be making up silly ideas, I don't know.  

Hardly silly -- have you seen Kernel#extend? :-) You can unextend too,
in the sense of undefining methods, though the extending techniques
are more formal and generalized than the unextending techniques.
There's been discussion in the past about having an #unextend or
#uninclude type of thing, and it's possible that selector namespaces,
if available in 2.0, will offer something like that functionality.

(I don't think the 'duck typing' concept is useful here.  That refers
more to the inferential nature of Ruby types; that is, the type
understood as the sum of the object's capabilities at a given moment,
based on what the object tells you and/or does for you.)

> I guess a better summery is that I viewed the type as something that was 
> changeable on an object and so therefor a.to_f! would still be changing THAT
> object.  This may not be the general view on types in ruby.  

Uh oh, all roads lead to type discussion :-)

I think the best way to look at the way it's all designed is: an
object is spawned, and has certain immutable characteristics that make
it that object, and which bootstrap it into object-space:
specifically, its class and its object id.  Neither of these things
can change; there's no such thing as being un- or re-spawned (which is
fine, since there's always a supply of new objects), and by definition
an object which has a different id is a different object.

Once spawned and bootstrapped, the object has a lot of freedom.  It
can be extended, unextended, respond this way and that to an arbitrary
number of methods, for arbitrary durations, and so on.  But it's still
itself; that is, all of this freedom (which is basically freedom of
type) takes place within the bootstrapping process I've described.

This is also why there's no String#split!, even though people
sometimes try it :-)  You can split a string, but you get an array --
a new object.  

You might be interested to look through the archives for discussion of
the idea of "become", which is probably the closest thing to what
you're describing among things that have been kicked around on the
list.  I think, though, that it tends to come up against both the
question of what it would mean, given Ruby's design, and the question
of whether it would really add anything (which might depend on what it
would mean :-)


David

-- 
David A. Black
[e-mail]