Feature #3072: Classes Inheriting from Data

• Status: Closed
• Assignee: matz (Yukihiro Matsumoto)
• Target version: 2.6

[runpaint (Run Paint Run Run)]

=begin
As I understand it, the Data class is an internal abstraction, not intended to be exposed to userland like this.

ObjectSpace.each_object(Class).select{|c| c < Data}
=> [Encoding::Converter, NameError::message]
=end

[nobu (Nobuyoshi Nakada)]

=begin
Hi,

At Thu, 1 Apr 2010 08:09:14 +0900,
Run Paint Run Run wrote in [ruby-core:29186]:

As I understand it, the Data class is an internal
abstraction, not intended to be exposed to userland like
this.

ObjectSpace.each_object(Class).select{|c| c < Data}
=> [Encoding::Converter, NameError::message]

Sorry, I'm not sure you think what should not be exposed.
Could you elaborate?

--
Nobu Nakada

=end

[runpaint (Run Paint Run Run)]

=begin
The Data class as a superclass. Why does it participate in the class hierarchy? Does it have some semantic relevance I'm unaware of?
=end

[shyouhei (Shyouhei Urabe)]

=begin
A class is a datatype. If one class and another have real identical data structures in common, there should be some relationships between them. Note what I'm talking about is about their data structures; not their behaviours. Ruby has ducky types so class inheritance depends exclusively to their ways of storing data. Data class is there because two T_DATA based classes should have some relationships in between.

Another reason why it is visible to you, is that MRI tend not to hide its internals to chat you. If you have any good reason to hide the class from your eyes, there can be chances for us to do so. But we have not met such reasons.
=end

[runpaint (Run Paint Run Run)]

=begin

Data class is there because two T_DATA based classes should have some
relationships in between.

Yet the two aforementioned classes are, from a user's perspective, as different as can be. What is the relationship between the two that the superclass is maintaining?

Or, what Joel said.
=end

[murphy (Kornelius Kalnbach)]

=begin
On 02.04.10 08:59, Joel VanderWerf wrote:

Agreed, if it's there it should be exposed. But still not sure why it's
there?
The name is awkward, too...I keep confusing it with DATA. Just me?

[murphy]

=end

[shyouhei (Shyouhei Urabe)]

=begin

What is the relationship between the two that the superclass is maintaining?

The struct RData.

OK, I admit its name is poor. I admit there are many extensions that use Data_Wrap_Struct without inheriting Data class. Things are not going as planned at this point. But the plan itself is what I explained.

And did I mention there are possibilities for changing the situation when you can persuade us?
=end

[nobu (Nobuyoshi Nakada)]

=begin
Hi,

At Sat, 3 Apr 2010 05:00:04 +0900,
Shyouhei Urabe wrote in [ruby-core:29232]:

OK, I admit its name is poor. I admit there are many
extensions that use Data_Wrap_Struct without inheriting Data
class. Things are not going as planned at this point. But
the plan itself is what I explained.

And did I mention there are possibilities for changing the
situation when you can persuade us?

Regarding the implementation, T_OBJECT and T_DATA methods are
guaranteed not to make any asumption on the internal structure
of their objects. So you can use T_OBJECT for Data_Wrap_Struct
instead. A possibile plan would be removal Data class and
replacement by rb_cObject, but I can't estimate how it will
affect widely.

--
Nobu Nakada

=end

[mame (Yusuke Endoh)]

• Assignee set to matz (Yukihiro Matsumoto)
• Target version set to 3.0

=begin
Hi,

At least, this is not a bug.
It is not harmful to be able to access Data class, is it?
In addition, we cannot change it soon for the compatibility
reason.

I move this ticket to Feature tracker with changing target.
The name of "Data" is, indeed, very poor.
And it is also arguable why Data is needed.
Let's discuss and refine it towards 2.0.

--
Yusuke Endoh [e-mail]
=end

[runpaint (Run Paint Run Run)]

=begin

What is the relationship between the two that the superclass is maintaining?
The struct RData.

Which is utterly irrelevant to the user. :-) A common superclass should imply common behaviour, not reveal a dubious artifact of an implementation. FWIW, Yusuke's proposal is agreeable to me, as it is evident that a solution requires serious thought.
=end

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Assigned

=begin

=end

[naruse (Yui NARUSE)]

• Project changed from Ruby master to 14
• Category deleted (core)
• Target version deleted (3.0)

[naruse (Yui NARUSE)]

• Project changed from 14 to Ruby master

[mame (Yusuke Endoh)]

• Description updated (diff)
• Target version set to 2.6

[mame (Yusuke Endoh)]

Matz, I think there are no longer reason to keep Data class. Like Fixnum/Bignum unification, how about deleting it?

[matz (Yukihiro Matsumoto)]

Agreed. How about making Data alias to Object.
It may be removed in the future (3.0?).

Matz.

[nobu (Nobuyoshi Nakada)]

• Status changed from Assigned to Closed

Applied in changeset trunk|r60930.

---

object.c: deprecate Data

• object.c (InitVM_Object): Data is deprecated now.
  [Feature #3072]