Project

General

Profile

Actions

Feature #3072

closed

Classes Inheriting from Data

Added by runpaint (Run Paint Run Run) almost 14 years ago. Updated over 6 years ago.

Status:
Closed
Target version:
[ruby-core:29186]

Description

=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

Actions #1

Updated by nobu (Nobuyoshi Nakada) almost 14 years ago

=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

Actions #2

Updated by runpaint (Run Paint Run Run) almost 14 years ago

=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

Actions #3

Updated by shyouhei (Shyouhei Urabe) almost 14 years ago

=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

Actions #4

Updated by runpaint (Run Paint Run Run) almost 14 years ago

=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

Actions #5

Updated by murphy (Kornelius Kalnbach) almost 14 years ago

=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

Actions #6

Updated by shyouhei (Shyouhei Urabe) almost 14 years ago

=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

Actions #7

Updated by nobu (Nobuyoshi Nakada) almost 14 years ago

=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

Actions #8

Updated by mame (Yusuke Endoh) almost 14 years ago

  • 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
=end

Actions #9

Updated by runpaint (Run Paint Run Run) almost 14 years ago

=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

Actions #10

Updated by shyouhei (Shyouhei Urabe) over 13 years ago

  • Status changed from Open to Assigned

=begin

=end

Actions #11

Updated by naruse (Yui NARUSE) over 12 years ago

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

Updated by naruse (Yui NARUSE) over 12 years ago

  • Project changed from 14 to Ruby master

Updated by mame (Yusuke Endoh) over 11 years ago

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

Updated by mame (Yusuke Endoh) over 6 years ago

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

Updated by matz (Yukihiro Matsumoto) over 6 years ago

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

Matz.

Actions #16

Updated by nobu (Nobuyoshi Nakada) over 6 years ago

  • 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]
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0