Why is to_a going to be obsolete?

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

Patrick Bennett wrote:

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

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. :frowning:
Matz, somebody? Why is to_a being obsoleted? :frowning:

Gennady wrote:

···

Patrick Bennett wrote:

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

Gennady.

Gennady wrote:

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

Don’t get too fond of it :wink:

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

Patrick Bennett wrote:

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. :frowning:
Matz, somebody? Why is to_a being obsoleted? :frowning:

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.

···

Gennady wrote:

Patrick Bennett wrote:

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

Gennady.

Joel VanderWerf wrote:

Gennady wrote:

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

Don’t get too fond of it :wink:

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.

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. :slight_smile: Anyway,
isn’t that a bit inconsistent?

M.

···

On Sat, 24 Jan 2004 02:25:59 +0900, Patrick Bennett patrick.bennett@inin.com wrote:

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

“Joel VanderWerf” wrote:

Don’t get too fond of it :wink:

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 :slight_smile:
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”]]
#----------

In a later post, “Dan Janowski” wrote:

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

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.

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.

···

On Friday 23 January 2004 06:43 pm, Gennady wrote:

Patrick Bennett wrote:

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. :frowning:
Matz, somebody? Why is to_a being obsoleted? :frowning:

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.

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.

-Mark

···

On Sat, Jan 24, 2004 at 01:17:20AM +0100, Michael Vondung wrote:

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. :slight_smile: Anyway,
isn’t that a bit inconsistent?

daz wrote:

“Joel VanderWerf” wrote:

Don’t get too fond of it :wink:

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 :slight_smile:
Hash#to_a access is blocked by your code as well as Object#to_a.

Quite right. The example shouldn’t have been a hash, since Hash#to_a
isn’t (AFAIK) going away any time soon. A better example:

irb(main):001:0> [*Class]
=> [Class]
irb(main):002:0> class Object; undef :to_a; end
=> nil
irb(main):003:0> [*Class]
NoMethodError: undefined method `to_a’ for Class:Class
from (irb):3

IMHO, the future is not made gloomy by this change :slight_smile:

Linus Sellberg wrote:

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

Exactly…

T. Onoma wrote:

Patrick Bennett wrote:

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. :frowning:
Matz, somebody? Why is to_a being obsoleted? :frowning:

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.

···

On Friday 23 January 2004 06:43 pm, Gennady wrote:

Hi,

···

In message “Re: Why is to_a going to be obsolete?” on 04/01/24, “T. Onoma” transami@runbox.com writes:

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.

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…

···

On Saturday 24 January 2004 01:29 am, Mark J. Reed wrote:

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.

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.

···

On Friday 23 January 2004 10:37 pm, Gennady wrote:

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

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

···

On Jan 23, 2004, at 11:19 PM, Yukihiro Matsumoto wrote:

Hi,

In message “Re: Why is to_a going to be obsolete?” > on 04/01/24, “T. Onoma” transami@runbox.com writes:

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

···

On Jan 23, 2004, at 11:19 PM, Yukihiro Matsumoto wrote:

Hi,

In message “Re: Why is to_a going to be obsolete?” > on 04/01/24, “T. Onoma” transami@runbox.com writes:

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