Why is to_a going to be obsolete?

[Patrick Bennett]

I find it immensely useful when dealing with arrays to be able to
convert a source argument (that may or may not be in an array) into an
array so I can concatenate it, perform a set-union on it, etc. with a
destination array.
What is the real reason for this, and if it's being obsoleted, what am I
supposed to use instead if I need to insure I'm dealing with an array ?

Thanks,
Patrick Bennett

 

[Gennady]

I find it immensely useful when dealing with arrays to be able to
convert a source argument (that may or may not be in an array) into an
array so I can concatenate it, perform a set-union on it, etc. with a
destination array.
What is the real reason for this, and if it's being obsoleted, what am I
supposed to use instead if I need to insure I'm dealing with an array ?

Thanks,
Patrick Bennett

I was also surprised to learn that Object#to_a is going to be obsolete.
However, I immediately found a replacement for it that I like even more:

instead of doing
o.to_a

I do now
[ *o ]

And this is not reported as obsolete in Ruby 1.8.1 yet ;-)

Gennady.

 

[Patrick Bennett]

Hmmm, thanks, but it's a bit 'non-obvious' to casual Ruby programmers
(who will have to understand my code). 'to_a' is pretty darn clear.
Matz, somebody? Why is to_a being obsoleted?

I find it immensely useful when dealing with arrays to be able to
convert a source argument (that may or may not be in an array) into
an array so I can concatenate it, perform a set-union on it, etc.
with a destination array.
What is the real reason for this, and if it's being obsoleted, what
am I supposed to use instead if I need to insure I'm dealing with an
array ?

I was also surprised to learn that Object#to_a is going to be
obsolete. However, I immediately found a replacement for it that I
like even more:

instead of doing
o.to_a

I do now
[ *o ]

And this is not reported as obsolete in Ruby 1.8.1 yet ;-)

Gennady.

 

[Gennady]

Hmmm, thanks, but it's a bit 'non-obvious' to casual Ruby programmers
(who will have to understand my code). 'to_a' is pretty darn clear.
Matz, somebody? Why is to_a being obsoleted?

I would not call "to_a" very obvious, as compared to, say, "to_array"
(if one existed). "[ *o ]" is more obvious in a sense that it is
comprised of two constructs one MUST know to read any Ruby program: "[]"
makes an array and "*" expands an object in-place.

Gennady.

I find it immensely useful when dealing with arrays to be able to
convert a source argument (that may or may not be in an array) into
an array so I can concatenate it, perform a set-union on it, etc.
with a destination array.
What is the real reason for this, and if it's being obsoleted, what
am I supposed to use instead if I need to insure I'm dealing with an
array ?

I was also surprised to learn that Object#to_a is going to be
obsolete. However, I immediately found a replacement for it that I
like even more:

instead of doing
o.to_a

I do now
[ *o ]

And this is not reported as obsolete in Ruby 1.8.1 yet ;-)

Gennady.

 

[Joel VanderWerf]

I was also surprised to learn that Object#to_a is going to be obsolete.
However, I immediately found a replacement for it that I like even more:

instead of doing
o.to_a

I do now
[ *o ]

And this is not reported as obsolete in Ruby 1.8.1 yet ;-)

Don't get too fond of it

irb(main):016:0> [~] irb
irb(main):001:0> h = {1=>2, :three=>"four"}
=> {1=>2, :three=>"four"}
irb(main):002:0> [*h]
=> [[1, 2], [:three, "four"]]
irb(main):003:0> class << h
irb(main):004:1> undef :to_a
irb(main):005:1> end
=> nil
irb(main):006:0> h.to_a
NoMethodError: undefined method `to_a' for {1=>2, :three=>"four"}:Hash
from (irb):6
irb(main):007:0> [*h]
NoMethodError: undefined method `to_a' for {1=>2, :three=>"four"}:Hash
from (irb):7

 

[Gennady]

I was also surprised to learn that Object#to_a is going to be
obsolete. However, I immediately found a replacement for it that I
like even more:

instead of doing
o.to_a

I do now
[ *o ]

And this is not reported as obsolete in Ruby 1.8.1 yet ;-)

Don't get too fond of it

irb(main):016:0> [~] irb
irb(main):001:0> h = {1=>2, :three=>"four"}
=> {1=>2, :three=>"four"}
irb(main):002:0> [*h]
=> [[1, 2], [:three, "four"]]
irb(main):003:0> class << h
irb(main):004:1> undef :to_a
irb(main):005:1> end
=> nil
irb(main):006:0> h.to_a
NoMethodError: undefined method `to_a' for {1=>2, :three=>"four"}:Hash
from (irb):6
irb(main):007:0> [*h]
NoMethodError: undefined method `to_a' for {1=>2, :three=>"four"}:Hash
from (irb):7

It shows only that currently '*' for hashes implemented via to_a, no more.

In any rate, I am with OP on this -- it would be nice to hear from Matz
about Object#to_a becoming obsolete and relevance of "[ *o ]" for the
future.

Gennady.

 

[Linus Sellberg]

I would not call "to_a" very obvious, as compared to, say, "to_array"

Compare it with to_i and to_s.

Then suddenly it is a wonder of orthogonality , and since they are
more common, then to_a is expected behaviour, imo.

Which not to say that the [* foo] shouldn't work as well.

 

[Patrick Bennett]

Then suddenly it is a wonder of orthogonality , and since they are
more common, then to_a is expected behaviour, imo.

Exactly...

 

[T. Onoma]

Hmmm, thanks, but it's a bit 'non-obvious' to casual Ruby programmers
(who will have to understand my code). 'to_a' is pretty darn clear.
Matz, somebody? Why is to_a being obsoleted?

I would not call "to_a" very obvious, as compared to, say, "to_array"
(if one existed). "[ *o ]" is more obvious in a sense that it is
comprised of two constructs one MUST know to read any Ruby program: "[]"
makes an array and "*" expands an object in-place.

I hadn't heard of this deprecation. Waht is the reasoning? If x.to_a is going
away, to be exchanged for the use of [*x], will to_h also follow and be
replaced by [**x]?

T.

 

[Gennady]

Hmmm, thanks, but it's a bit 'non-obvious' to casual Ruby programmers
(who will have to understand my code). 'to_a' is pretty darn clear.
Matz, somebody? Why is to_a being obsoleted?

I would not call "to_a" very obvious, as compared to, say, "to_array"
(if one existed). "[ *o ]" is more obvious in a sense that it is
comprised of two constructs one MUST know to read any Ruby program: "[]"
makes an array and "*" expands an object in-place.

I hadn't heard of this deprecation. Waht is the reasoning? If x.to_a is going
away, to be exchanged for the use of [*x], will to_h also follow and be
replaced by [**x]?

T.

As far as I understand, only the default to_a (Object#to_a) is becoming
obsolete (it gives a warning in Ruby 1.8.1). Many built-in classes will
continue to provide their own to_a implementations. As for "to_h", it
was never a default method, so you sarcasm is not justified here ;-).

But again, I would love to hear about it from somebody intimate with
Ruby development.

Gennady.

 

[T. Onoma]

As far as I understand, only the default to_a (Object#to_a) is becoming
obsolete (it gives a warning in Ruby 1.8.1). Many built-in classes will
continue to provide their own to_a implementations. As for "to_h", it
was never a default method, so you sarcasm is not justified here ;-).

sarcasm? please don't miss understand me. i was actually being quite sincere,
along this line of reasoning: since the only two built-in collection classes
in ruby are Array and Hash, and **x is the projected syntax for the new
keyword method arguments, i thought perhaps their might be something to this
possibility.

But again, I would love to hear about it from somebody intimate with
Ruby development.

yes, me too.

thanks,
T.

 

[Michael Vondung]

Hmmm, thanks, but it's a bit 'non-obvious' to casual Ruby programmers
(who will have to understand my code). 'to_a' is pretty darn clear.

As one of those who use Ruby casually, I wholeheartedly concur. to_s
and to_i were among the first things I learned, so to_a always made
perfect sense to me. [ *o ] may make more sense to more experienced
programmers, but it merely seems more cryptic to _me_. Anyway,
isn't that a bit inconsistent?

M.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Why is to_a going to be obsolete?"

|If x.to_a is going
|away, to be exchanged for the use of [*x], will to_h also follow and be
|replaced by [**x]?

Try Array(x).

matz.

 

[Patrick Bennett]

Ah, thanks! I see that it returns the object as-is if it's already an
array, which is what I need.
I'm still curious though - may I ask why Object.to_a is going away?

Thanks,
Patrick Bennett

 

[T. Onoma]

No, because to_a will still exist and will still be the way to get
arrays out of objects which are collections of some sort.

All that's going away is the default to_a of class Object, which
returns a one-elment array containing the receiver. That has never
made sense to me. I mean, if I have an object obj and I want an
array containing it, I would just write [ obj ]. If the object may
or may not already be an array and I don't want to add a level of
arrayness if it is, which feels fuzzy but never mind, then I would
write [ *obj ]. There's no new syntax there; that's just how you do
that in Ruby.

Calling to_a would not occur to me unless I had something that I knew was
some sort of collection object and wanted to get its members as an
array - that's what to_a was made for, and that's what it'll *still* be
for even if Object#to_a -> [ self ] goes away.

ah. thank you mark. that makes this whole subject much more comprehensible.

- T.

P.S. i just noticed that my notion of a ** hashing operator should be enclosed
in script brackets instead or square brackets, i.e. {**x} not [**x]. not that
it really matters, but nonetheless...

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Why is to_a going to be obsolete?"

|I'm still curious though - may I ask why Object.to_a is going away?

I wanted to reserve "to_a" method for Array-like objects, such as
Enumerables.

matz.

 

[Patrick Bennett]

I wanted to reserve "to_a" method for Array-like objects, such as
Enumerables.

Ok, now that I know about Array.new's behavior, it makes a bit more sense now. Thanks Matz.

Cheers...
Patrick Bennett

 

[Dan Janowski]

Hi,

In message "Re: Why is to_a going to be obsolete?"

|If x.to_a is going
|away, to be exchanged for the use of [*x], will to_h also follow and
be
|replaced by [**x]?

Try Array(x).

But should it not be up to 'x' to decide how it should be represented
as an Array? What would I do in a class I define to give it a way to
represent itself as an Array using this?

Dan

 

[Dan Janowski]

Hi,

In message "Re: Why is to_a going to be obsolete?"

|If x.to_a is going
|away, to be exchanged for the use of [*x], will to_h also follow and
be
|replaced by [**x]?

Try Array(x).

My apology, I read a few more messages: to_a will still be the
sanctioned way for an object to emit itself as an array, but Object
will not include such a method. Correct?

Dan

 

[daz]

Don't get too fond of it

irb(main):016:0> [~] irb
irb(main):001:0> h = {1=>2, :three=>"four"}
=> {1=>2, :three=>"four"}
irb(main):002:0> [*h]
=> [[1, 2], [:three, "four"]]
irb(main):003:0> class << h
irb(main):004:1> undef :to_a
irb(main):005:1> end
=> nil
irb(main):006:0> h.to_a
NoMethodError: undefined method `to_a' for {1=>2, :three=>"four"}:Hash
from (irb):6
irb(main):007:0> [*h]
NoMethodError: undefined method `to_a' for {1=>2, :three=>"four"}:Hash
from (irb):7

I don't think the future is so gloomy
Hash#to_a access is blocked by your code as well as Object#to_a.

#----------
p Object.instance_methods(true).grep(/^to_/)
module Kernel
undef :to_a
end
p Object.instance_methods(true).grep(/^to_/)

h = {1=>2, :three=>"four"}
p [*h]

#-> ["to_a", "to_s"]
#-> ["to_s"]
#-> [[1, 2], [:three, "four"]]
#----------

My apology, I read a few more messages: to_a will still be the
sanctioned way for an object to emit itself as an array, but Object
will not include such a method. Correct?

Dan

That's how I see it.


daz