Feature #3072
closedClasses Inheriting from Data
Added by runpaint (Run Paint Run Run) over 14 years ago. Updated over 6 years ago.
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
Updated by nobu (Nobuyoshi Nakada) over 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
Updated by runpaint (Run Paint Run Run) over 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
Updated by shyouhei (Shyouhei Urabe) over 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
Updated by runpaint (Run Paint Run Run) over 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
Updated by murphy (Kornelius Kalnbach) over 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
Updated by shyouhei (Shyouhei Urabe) over 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
Updated by nobu (Nobuyoshi Nakada) over 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
Updated by mame (Yusuke Endoh) over 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 mame@tsg.ne.jp
=end
Updated by runpaint (Run Paint Run Run) about 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
Updated by shyouhei (Shyouhei Urabe) almost 14 years ago
- Status changed from Open to Assigned
=begin
=end
Updated by naruse (Yui NARUSE) almost 13 years ago
- Project changed from Ruby master to 14
- Category deleted (
core) - Target version deleted (
3.0)
Updated by naruse (Yui NARUSE) almost 13 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) almost 7 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.
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]