Feature #3072

Classes Inheriting from Data

Added by Run Paint Run Run about 4 years ago. Updated over 1 year ago.

[ruby-core:29186]
Status:Assigned
Priority:Low
Assignee:Yukihiro Matsumoto
Category:-
Target version:next minor

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

History

#1 Updated by Nobuyoshi Nakada about 4 years ago

=begin
Hi,

At Thu, 1 Apr 2010 08:09:14 +0900,
Run Paint Run Run wrote in :

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

#2 Updated by Run Paint Run Run about 4 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

#3 Updated by Shyouhei Urabe about 4 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

#4 Updated by Run Paint Run Run about 4 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

#5 Updated by Kornelius Kalnbach about 4 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

#6 Updated by Shyouhei Urabe about 4 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 DataWrapStruct 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

#7 Updated by Nobuyoshi Nakada about 4 years ago

=begin
Hi,

At Sat, 3 Apr 2010 05:00:04 +0900,
Shyouhei Urabe wrote in :

OK, I admit its name is poor. I admit there are many
extensions that use DataWrapStruct 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, TOBJECT and TDATA methods are
guaranteed not to make any asumption on the internal structure
of their objects. So you can use TOBJECT for DataWrapStruct
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

#8 Updated by Yusuke Endoh about 4 years ago

  • Assignee set to Yukihiro Matsumoto
  • Target version set to Next Major

=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

#9 Updated by Run Paint Run Run almost 4 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

#10 Updated by Shyouhei Urabe over 3 years ago

  • Status changed from Open to Assigned

=begin

=end

#11 Updated by Yui NARUSE over 2 years ago

  • Project changed from ruby-trunk to CommonRuby
  • Category deleted (core)
  • Target version deleted (Next Major)

#12 Updated by Yui NARUSE over 2 years ago

  • Project changed from CommonRuby to ruby-trunk

#13 Updated by Yusuke Endoh over 1 year ago

  • Description updated (diff)
  • Target version set to next minor

Also available in: Atom PDF