Destructive type conversion (to_i!, to_f!)

[Charles Comstock]

Hi,
There have been a few times in which I have wanted to destructively change the
type of a variable, yet as fas I can determine there are only to_i and to_f and
not to_i! or to_f!. It seemed like these would be useful sets of methods to
have in addition to the existing to_i, to_f methods. In particular this would
be nice for situations like:

ARGV[0].to_i!
if(ARGV[0] > 5) {...}

or if you had read in a config file into keyname/value string pairs in a hash
I commonly find myself using something like:

config['accuracy'] = config['accuracy'].to_i

this would be much simpler if it was simply

config['radix'].to_i!

While not as useful in expression statements these would be nice and analogous
to the +=, -= operators that automatically get defined based on definition of
the matching operator. It would be nice if the type conversion methods had
something that was similar to that.

Anyway, seemed useful to me, wondered what everyone else thought,

Charles Comstock

[David A. Black]

Hi --

On Sun, 23 Nov 2003, Charles Comstock wrote:

> Hi,
> There have been a few times in which I have wanted to destructively change the
> type of a variable, yet as fas I can determine there are only to_i and to_f and
> not to_i! or to_f!. It seemed like these would be useful sets of methods to
> have in addition to the existing to_i, to_f methods. In particular this would
> be nice for situations like:
>
> ARGV[0].to_i!
> if(ARGV[0] > 5) {...}
>
> or if you had read in a config file into keyname/value string pairs in a hash
> I commonly find myself using something like:
>
> config['accuracy'] = config['accuracy'].to_i
>
> this would be much simpler if it was simply
>
> config['radix'].to_i!
>
> While not as useful in expression statements these would be nice and analogous
> to the +=, -= operators that automatically get defined based on definition of
> the matching operator. It would be nice if the type conversion methods had
> something that was similar to that.
>
> Anyway, seemed useful to me, wondered what everyone else thought,

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

(I can't remember if Matz commented on it.)


David

--
David A. Black
[email]dblack@wobblini.net[/email]

[Charles Comstock]

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.

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.

Charles Comstock

[David A. Black]

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
[email]dblack@wobblini.net[/email]

[Josef 'Jupp' SCHUGT]

Hi!

* Charles Comstock; 2003-11-22, 23:55 UTC:

> ARGV[0].to_i!
> if(ARGV[0] > 5) {...}

For me the least surprising answer to the question what

a = [0,1,2,3,4,5]
a[10].to_i!
p a

results in given the choices

a) [0, 1, 2, 3, 4, 5]
b) [0, 1, 2, 3, 4, 5, nil, nil, nil, nil, 0]
c) syntax error

is c.

Josef 'Jupp' Schugt
--
.-------.
message > 100 kB? / | |
sender = spammer? / | R.I.P.|
text = spam? / ___| |___

[Robert Klemme]

"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0311221639400.10991-100000@wobblini.net...
[snip]

> 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.

[snip]

> 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 :-)

And there's always the workaround of an instance holding a reference to
another instance that is exchanged:

class Ref
def initialize(obj=nil); replace(obj); end
def get; @obj; end
def replace(obj); @obj = obj; end
def clear; replace(nil); end
end

.... or probably a more sophisticated version using Delegator or
SimpleDelegator.

As long as you only refer instances of Ref, the type of the referenced
instance can change arbitrarily.

Regards

robert