Self_parent

ruby-talk
1

i was wondering what others thought of the idea of having a built in
reference to the creation-parent for every object? much like the built
in self reference which points to the object, self_parent would point to
the object in which self was created. for example:

class S
def initialize
self_parent.hello
end
end

class P
def initialize
@s = S.new
end
def hello
p "hello world"
end
end

p = P.new --> hello world

in my experience, i have encounter numerous places where i’d like access
to the parent object, in these cases i’ve had to pass the parent’s self
to the child on instatiation. i.e. @s = S.new(self), and store that
within an instance variable of the child.

since it’s only a reference, i would think there would be little
overhead to keeping this reference available automatically. in fact, i
imagine the information is already there, just without a way to get to
it. i think numerous programs could make use of such a feature.

what’ya think?

~transami

···

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

2

Hello –

i was wondering what others thought of the idea of having a built in
reference to the creation-parent for every object? much like the built
in self reference which points to the object, self_parent would point to
the object in which self was created. for example:

class S
def initialize
self_parent.hello
end
end

class P
def initialize
@s = S.new
end
def hello
p “hello world”
end
end

p = P.new → hello world

in my experience, i have encounter numerous places where i’d like access
to the parent object, in these cases i’ve had to pass the parent’s self
to the child on instatiation. i.e. @s = S.new(self), and store that
within an instance variable of the child.

My first reaction, which I’ll go ahead and express although I’m kind
of just thinking out loud (as it were), is that I don’t think of this
as a parent-child relationship… though I’m not sure what the right
term would be. (previous_value_of_self? It is kind of like creating
a stack of self’s.) Anyway, “self_parent” would look weird because
then you’d probably sometimes call it as self.self_parent :slight_smile: In
general, I think it could lead to encapsulation-breaking things, like
classes prying into instances of their own subclasses. (Not that
that’s currently impossible.)

I’d be interested in seeing an example of the kind of situation where
you’ve wanted to have this, if you’ve got a small-ish size case.

David

···

On Fri, 5 Jul 2002, Tom Sawyer wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

3

“Tom Sawyer” transami@transami.net wrote in
…

in self reference which points to the object, self_parent would point to

Normally I not that picky about names but ``self_parent’’ , especially
in combination with your example, seems to be a rather misleading
term.

…

class S
def initialize
self_parent.hello
end
end

class P
def initialize
@s = S.new
end
def hello
p “hello world”
end
end
…

Have you tried implementing this in pure Ruby - is

···

class S
def initialize(calling_self)
calling_self.hello
end
end

class P
def initialize
@x = S.new self
end
def hello
p “hello World”
end
end

short enough?

/Christoph

4

all my real examples are pretty large, mostly to do with using the REXML
stream parser. also the utility of this really only becaomes significant
when the program is substatial. if you only have one or two variables to
worry about it’s easy enough to just pass those. but if you need access
to a handful or more, and perhaps some of the parents methods, then this
becomes a wonderful convience.

but let me throw together a little example here just for some reference:

class Customer
attr_reader :name, :address
def initialize(name, address)
@name = name
@address = Address.new(address,self)
end
def pretty_name
return @name.upcase
end
end

class Address
def initialize(address, customer)
@address = address
@customer = customer
end
def print_label
puts @customer.pretty_name
puts @address
end
end

c = Customer.new(“John Doe”, “111 Test Ln.\n Santa Fe, NM 87501”)
c.address.print_label

as you can see, i passed self and stored it to get access to the
customer instance from within address object. but with self_parent this
becomes:

class Customer
attr_reader :name, :address
def initialize(name, address)
@name = name
@address = Address.new(address)
end
def pretty_name
return @name.upcase
end
end

class Address
def initialize(address)
@address = address
end
def print_label
puts self_parent.pretty_name
puts @address
end
end

c = Customer.new(“John Doe”, “111 Test Ln.\n Santa Fe, NM 87501”)
c.address.print_label

no need to pass self and explicitly store it. so there’s a fictional
example for you. in the real world there are many cases of such a
parent-child relationship. in fact i think REXML has an explicit Parent
class it uses to glue such realtionships together. hiearchy structures
too (like a tree) are another area in which a parent-child relationships
of this sort are used. and i’m sure there are many others.

also, like i said earlier, my bet is that this reference to the
creation-parent is already stored in the ruby interpreter to some
degree. i bet there wouldn’t be much to adding access to it. yes, there
may be a couple error checks needed to stave-off recursive type loops,
but, then again, you can already do such crazy things anyway.

~transami

···

On Thu, 2002-07-04 at 11:45, David Alan Black wrote:

Hello –

On Fri, 5 Jul 2002, Tom Sawyer wrote:

i was wondering what others thought of the idea of having a built in
reference to the creation-parent for every object? much like the built
in self reference which points to the object, self_parent would point to
the object in which self was created. for example:

class S
def initialize
self_parent.hello
end
end

class P
def initialize
@s = S.new
end
def hello
p “hello world”
end
end

p = P.new → hello world

in my experience, i have encounter numerous places where i’d like access
to the parent object, in these cases i’ve had to pass the parent’s self
to the child on instatiation. i.e. @s = S.new(self), and store that
within an instance variable of the child.

My first reaction, which I’ll go ahead and express although I’m kind
of just thinking out loud (as it were), is that I don’t think of this
as a parent-child relationship… though I’m not sure what the right
term would be. (previous_value_of_self? It is kind of like creating
a stack of self’s.) Anyway, “self_parent” would look weird because
then you’d probably sometimes call it as self.self_parent :slight_smile: In
general, I think it could lead to encapsulation-breaking things, like
classes prying into instances of their own subclasses. (Not that
that’s currently impossible.)

I’d be interested in seeing an example of the kind of situation where
you’ve wanted to have this, if you’ve got a small-ish size case.

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

5

“Christoph” chr_news@gmx.net wrote in
…
…

Have you tried implementing this in pure Ruby - is

class S
def initialize(calling_self)
calling_self.hello
end
end

class P
def initialize
@x = S.new self
end
def hello
p “hello World”
end
end

short enough?

A never mind … I missed your fictional example
(and calling_self is not the right name either).

Anyway my point was that adding the four letter word s…
isn’t much of an overhead (keystroke wise) to merit your,
ihmo wrong headed, proposed language change.

/Christoph

6

all my real examples are pretty large, mostly to do with using the REXML
stream parser. also the utility of this really only becaomes significant
when the program is substatial. if you only have one or two variables to
worry about it’s easy enough to just pass those. but if you need access
to a handful or more, and perhaps some of the parents methods, then this
becomes a wonderful convience.

How would an object know the methods of an arbitray parent? Doesn’t this
completly couple the two objects? The parent (reasonably) expects the
object it creates to implement certain methods; the newly-created object
expects the parent to implement certain methods.

Perhaps I misunderstand what you need to accomplish or how self_parent
would be implemented, but it sounds like it would encourage fragile designs
without any real gains.

In your example, Address requires an object that implements pretty_name.
It works with any parent if that parent passes in a pretty_name-compliant
object. Having Address use self_parent means it only works when the
parent responds (and in the right way) to pretty_name. Changing the
Customer class can break the Address class, and vice versa.

James

7

class Customer
attr_reader :name, :address
def initialize(name, address)
@name = name
@address = Address.new(address,self)
end
def pretty_name
return @name.upcase
end
end

class Address
def initialize(address, customer)
@address = address
@customer = customer
end
def print_label
puts @customer.pretty_name
puts @address
end
end

c = Customer.new(“John Doe”, “111 Test Ln.\n Santa Fe, NM 87501”)
c.address.print_label

I understand that this is an invented example that may not show all the issues
involved, but …

In this case, wouldn’t it be just as simple to make print_label a method of
the Customer class, rather than the Address class? In fact, I would say that
this would be a more logical design, anyway, since one is presumably printing
the label in order to send something to that customer, not just to get
something to that particular address.

Just a thought and, as I say, may not make sense overall, since you’re just
giving us an example here.

8

Hi –

class Customer
attr_reader :name, :address
def initialize(name, address)
@name = name
@address = Address.new(address)
end
def pretty_name
return @name.upcase
end
end

class Address
def initialize(address)
@address = address
end
def print_label
puts self_parent.pretty_name
puts @address
end
end

c = Customer.new(“John Doe”, “111 Test Ln.\n Santa Fe, NM 87501”)
c.address.print_label

This introduces a dependency between objects, though, based on a kind
of “self” stack, which won’t necessarily mesh with the actual design
and behavior of the classes and objects.

For example, let’s say you wanted to refactor/rewrite Customer like
this:

class Factory
def Factory.make(thing,*args)
const_get(thing).new(*args)
end
end

class Customer
def initialize(name, address)
@name = name
@address = Factory.make(“Address”, address)
end
…
end

Not a very elegant example – but the point is, now you’re two "self"s
away, instead of one, but your Address objects are hardcoded to look
one “self” away.

I know Ruby allows for a lot of introspection… but I think relying
on this would constrain code and code growth significantly.

no need to pass self and explicitly store it. so there’s a fictional
example for you. in the real world there are many cases of such a
parent-child relationship. in fact i think REXML has an explicit Parent
class it uses to glue such realtionships together. hiearchy structures
too (like a tree) are another area in which a parent-child relationships
of this sort are used. and i’m sure there are many others.

REXML is specifically modeling the parent/child relationships of XML
in that class, though (I think). That’s different from a
language-level (I mean Ruby, not XML) description of one object as the
“parent” of another because the second object is created by a method
of the first object.

David

···

On Fri, 5 Jul 2002, Tom Sawyer wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

9

C’mon, for an object to be coupled to the one where it was created is
still a specific case, not the general one. I don’t think that in
puts "hello, world"' you want the string to be coupled to the object. Instead I think you'll want the coupling to be as clear as possible to who reads the code, and both x = X.new(self)’ and `x.parent = self’
do this pretty good, don’t they?

Massimiliano

···

On Fri, Jul 05, 2002 at 07:49:09AM +0900, Tom Sawyer wrote:

no need to pass self and explicitly store it. so there’s a fictional
example for you. in the real world there are many cases of such a
parent-child relationship.

10

David Alan Black wrote:

REXML is specifically modeling the parent/child relationships of XML
in that class, though (I think). That’s different from a
language-level (I mean Ruby, not XML) description of one object as the
“parent” of another because the second object is created by a method
of the first object.

Yes. A REXML parent/child relationship has nothing to do with object
inheritance, but rather describes a contains/contained by relationship.

This is clouded by the fact that, in XML, elements can be seen to ‘inherit’
attributes from their parents – namespaces, in particular. Still, this is
more of a scoping issue than a direct inheritance issue.

Put another way, parent/child in REXML is a homonym to parent/child in Ruby
– same words, different meaning.

···

–

… “Even the Mongols rejected Communism… are we more dumb?”
<|> — Russian newspaper headline supporting Yeltzin’s 1996 campaign
/|\
/|

11

In this case, wouldn’t it be just as simple to make print_label a method of
the Customer class, rather than the Address class? In fact, I would say that
this would be a more logical design, anyway, since one is presumably printing
the label in order to send something to that customer, not just to get
something to that particular address.

yes, that’s true --always a problem with off the cuff fictions like the
example i gave. but the idea of its use is clearer, i hope.

but what if both the child and the parent need use of a method that is
identical? in such a case you either have to give both classes identical
code, which is not very good code reuse. or you have to define a module
to mixin to both of them, which is what i do now, even if i only need it
for the that one parent and one child. and if you have another child
that needs to access a differnt method and yet share it with the parent.
well, that’s another seperate module to be mixed in, etc.

were really talking convience here as obviously one can pass self if
need be, currently.

~tom

···

On Thu, 2002-07-04 at 17:42, Harry Ohlsen wrote:

class Customer
attr_reader :name, :address
def initialize(name, address)
@name = name
@address = Address.new(address,self)
end
def pretty_name
return @name.upcase
end
end

class Address
def initialize(address, customer)
@address = address
@customer = customer
end
def print_label
puts @customer.pretty_name
puts @address
end
end

c = Customer.new(“John Doe”, “111 Test Ln.\n Santa Fe, NM 87501”)
c.address.print_label

I understand that this is an invented example that may not show all the issues
involved, but …

In this case, wouldn’t it be just as simple to make print_label a method of
the Customer class, rather than the Address class? In fact, I would say that
this would be a more logical design, anyway, since one is presumably printing
the label in order to send something to that customer, not just to get
something to that particular address.

Just a thought and, as I say, may not make sense overall, since you’re just
giving us an example here.

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

12

hi james,

isnt this simply a matter of design? and one that is really inherit in
OOP? when i inherit a class or mixin a module, i am depending on certain
instances and methods to exist. that’s the nature of OO designs, in
order to achive code reuse. its a given that if you change one thing
somewhere you can break something that depends on it. that’s always a
consideration, self_parent or no.

~transami

···

On Thu, 2002-07-04 at 17:40, james@rubyxml.com wrote:

all my real examples are pretty large, mostly to do with using the REXML
stream parser. also the utility of this really only becaomes significant
when the program is substatial. if you only have one or two variables to
worry about it’s easy enough to just pass those. but if you need access
to a handful or more, and perhaps some of the parents methods, then this
becomes a wonderful convience.

How would an object know the methods of an arbitray parent? Doesn’t this
completly couple the two objects? The parent (reasonably) expects the
object it creates to implement certain methods; the newly-created object
expects the parent to implement certain methods.

Perhaps I misunderstand what you need to accomplish or how self_parent
would be implemented, but it sounds like it would encourage fragile designs
without any real gains.

In your example, Address requires an object that implements pretty_name.
It works with any parent if that parent passes in a pretty_name-compliant
object. Having Address use self_parent means it only works when the
parent responds (and in the right way) to pretty_name. Changing the
Customer class can break the Address class, and vice versa.

James

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

13

hi david,

yes the REXML isn’t really a good example, it was just a passing
thought. you may a good point. using a “Factory” would add a
consideration for self_parent’s use. but i don’t see how it could
possibly “constrain code and code growth significantly.” when one
designs a program it is exactly that: designed. no what i’m saying?
self_parent is just another tool.

~transami

···

On Thu, 2002-07-04 at 17:45, David Alan Black wrote:

Hi –

On Fri, 5 Jul 2002, Tom Sawyer wrote:

class Customer
attr_reader :name, :address
def initialize(name, address)
@name = name
@address = Address.new(address)
end
def pretty_name
return @name.upcase
end
end

class Address
def initialize(address)
@address = address
end
def print_label
puts self_parent.pretty_name
puts @address
end
end

c = Customer.new(“John Doe”, “111 Test Ln.\n Santa Fe, NM 87501”)
c.address.print_label

This introduces a dependency between objects, though, based on a kind
of “self” stack, which won’t necessarily mesh with the actual design
and behavior of the classes and objects.

For example, let’s say you wanted to refactor/rewrite Customer like
this:

class Factory
def Factory.make(thing,*args)
const_get(thing).new(*args)
end
end

class Customer
def initialize(name, address)
@name = name
@address = Factory.make(“Address”, address)
end
…
end

Not a very elegant example – but the point is, now you’re two "self"s
away, instead of one, but your Address objects are hardcoded to look
one “self” away.

I know Ruby allows for a lot of introspection… but I think relying
on this would constrain code and code growth significantly.

no need to pass self and explicitly store it. so there’s a fictional
example for you. in the real world there are many cases of such a
parent-child relationship. in fact i think REXML has an explicit Parent
class it uses to glue such realtionships together. hiearchy structures
too (like a tree) are another area in which a parent-child relationships
of this sort are used. and i’m sure there are many others.

REXML is specifically modeling the parent/child relationships of XML
in that class, though (I think). That’s different from a
language-level (I mean Ruby, not XML) description of one object as the
“parent” of another because the second object is created by a method
of the first object.

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

14

by the way, this idea actually stems from an earlier desire to have
objects created by nested class definitions inherit their parent class
instance.

see: http://www.rubygarden.com/article.php?sid=236

just trying to solve the age old question:
“are you my mother?” - p.d.eastman
okay, i just opened myself up to all sorts of trouble now.

~transami :slight_smile:

···

On Fri, 2002-07-05 at 05:31, Massimiliano Mirra wrote:

On Fri, Jul 05, 2002 at 07:49:09AM +0900, Tom Sawyer wrote:

no need to pass self and explicitly store it. so there’s a fictional
example for you. in the real world there are many cases of such a
parent-child relationship.

C’mon, for an object to be coupled to the one where it was created is
still a specific case, not the general one. I don’t think that in
puts "hello, world"' you want the string to be coupled to the object. Instead I think you'll want the coupling to be as clear as possible to who reads the code, and both x = X.new(self)’ and `x.parent = self’
do this pretty good, don’t they?

Massimiliano

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

15

well, i just passed self, again. so imust ask you, how general is
general? so far, just about every sizable script i write i end up
passing self somewhere. “hello, world” is not a good example as it is an
utterly useless program. useful programs are much more complex, where
self passing is much more likely and useful.

sure passing self isn’t that bad. but i don’t think accessing the
creation-parent object is that uncommon.

···

On Fri, 2002-07-05 at 05:31, Massimiliano Mirra wrote:

C’mon, for an object to be coupled to the one where it was created is
still a specific case, not the general one. I don’t think that in
puts "hello, world"' you want the string to be coupled to the object. Instead I think you'll want the coupling to be as clear as possible to who reads the code, and both x = X.new(self)’ and `x.parent = self’
do this pretty good, don’t they?

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

16

james@rubyxml.com schrieb:

How would an object know the methods of an arbitray parent? Doesn’t this
completly couple the two objects? The parent (reasonably) expects the
object it creates to implement certain methods; the newly-created object
expects the parent to implement certain methods.

Yes, indeed. But let me think aloud a bit:

1.) Sometimes you have this tight coupling between two
classes/objects. Customer and Address perhaps is a bad
example as you can Address imagine to belong to other
containers too.
OTOH a relationship between an Order and an Orderline or an
Invoice and Invoiceline is much closer.

2.)
Designing that relationship as bidirectional navigable
(as expressible with the UML) is a possibility.
You could hand around orderlines and they keep the relation
to their container/master/whatever-term-you-want like with
closures at the technical level.

OTOH: Wouldn’t it be a better design to always hand over the
reference to the order or to the invoice instead of single
lines, and access the parts of it via the order’s/invoice’s
interface? (delegator). Otherwise the client of Order would
have a deep inside, how an order is implemented inside.
But: Wouldn’t that mean, that an Order has to implement
something like a Orderline interface?
(As I could not easily return a reference to one of its
orderlines …)

This tight coupling is an intimate knowledge between
Order and Orderline, and is directly understood by people
knowing the domain.
But looking at this: Some people here stated never need
to pass a self reference to a contained object. This would
mean to have a strictly uni-directional navigation troughout
the whole system.
And that’s IMHO not true, unless they make some design pull-ups to
strictly avoid callback and delegation.

Perhaps I misunderstand what you need to accomplish or how self_parent
would be implemented, but it sounds like it would encourage fragile designs
without any real gains.

Hum, not really. I’ve got the feeling that there should always be
two kind of interfaces.

First: The ‘inner’ one between two tightly coupled
classes/objects. Why shouldn’t be there a relation between
a class/object and its close “environment”?
(In comparision: Think of the effort of writing a shellscript
which gots everything explicitly as CL-options instead of
using the environmentvariables.)
They would communicate with each other in a form of call and
callback.

Second: The ‘outer’ one between a component and it’s
environment. To be useful in many “environments”, perhaps
contexts, the component should never rely on specific behaviour
or structure of its outer side. Here works the Law Of Demeter:
“Don’t talk to strangers”.

In this description a ‘component’ can be a single class or
a combination of tightly coupled, co-relating classes.

Looking into the real world, there are technical items
which can be assembled into many environments by having
a standardised “interface” (plug, switches …) but having
parts inside them which possibly never (hum I don’t like this
word) could be used outside in other combinations.

Coming to the original subject:

  • Yes, indeed it is a design decision to couple classes
    So to be open, the language has to support all (hum, most of)
    the decisions I made. Not necessarily language inherent (when
    passing self) but it could simplify things, if it would be
    possible (when having a self_composite reference, to give
    another name for that ;o) ).
    This is the fact with Ruby. Your design decisions are supported.
    In this case by using self.
  • As we’ve seen in the discussion in this thread, this is a
    design decision and not a general feature of classes in OOP.
    So this reference pointer can not be considered an every-class
    feature requirement.
    It is the special case the UML calls:
    Composition, meaning a one-to-many aggregation.
    And it is the special case this asssociation is bidirectional.
    Perhaps it would be worth thinking about a keyword in the
    language declaring a class as ‘bidirectional’, which, when
    using it, would introduce this self_composite reference?
  • But it would not be enough to have this keyword. You should
    declare more of this relationship. So you would declare the
    class to which this composition refers, to give the system
    ability to proof the structure at runtime just before
    calling a self_composite’s method.
    This would lead indirectly to a design language, where you
    would declare associations in another way than common today.
    The question then is: What about all the other kinds of
    associations, what about multiplicity?

I resume: This feature would lead to a totally other PL concept,
and leads outside of Ruby.

In your example, Address requires an object that implements pretty_name.

Indeed.

It works with any parent if that parent passes in a pretty_name-compliant
object.

Right.

Having Address use self_parent means it only works when the
parent responds (and in the right way) to pretty_name.

Indeed, that’s the problem with communication :slight_smile: .
The called object has to implement a method for the message.

Changing the
Customer class can break the Address class, and vice versa.

What you stated is a problem you always have when changing the
interface of a class which is used by other parts of the system
(like usual, as classes/objects exist to be used by other parts,
or they will be killed by the GC).

So changing the Customer class will have much more effect
to objects not mentionted here in the current discussion:
Its clients!

Using the self_whatever reference would not break the
rule of communication via interfaces.
It would only simplify the definition of a very special
kind of association.

And as I told, Customer->Address is a bad example.

Regarding to my examples:
Changing a class without knowing the relating (domain) model
(Order → Orderline) is a foolish attempt.
When knowing the (domain) model, changing the Order class
without having a look at the Orderline class (or vice versa)
should be considered a implementor’s offence.

BTW: Regarding the last post I read.
This is indeed not a matter of OO “inheritance”. But looking
at the ways to construct systems there are two relation
dimensions: inheritance and association.
It is interesting, that OO languages directly support only
the former one, but have no implicit mechanisms for the latter.
This is why this relations must be explicitly ‘generated’ out
of an UML diagram into code mechanisms (e.g by passing self).
But these mechanisms just are flexible enough to support the
very different kind of design decisions.

JM2C

Det

17

Hello –

···

On Fri, 5 Jul 2002, Sean Russell wrote:

David Alan Black wrote:

REXML is specifically modeling the parent/child relationships of XML
in that class, though (I think). That’s different from a
language-level (I mean Ruby, not XML) description of one object as the
“parent” of another because the second object is created by a method
of the first object.

Yes. A REXML parent/child relationship has nothing to do with object
inheritance, but rather describes a contains/contained by relationship.

Moreover, the notion of “self” at the time of object creation as the
parent of the created object is actually also not related to
object inheritance – which I think is part of what’s potentially
confusing about it, though even with renaming the problems with
coupling and dependencies would remain.

David

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

18

hi sean,

yes, the REXML site was probably not the best. but self_parent in effect
does give one a quick, simple and sort-of “natural” means of defining
contains/container relationships, such that a “contained” object can use
self_parent to “look up” to its “container” object.

accessible or not, there is a relationship between the two objects. the
one was created within the other --the creation-parent did in fact
create the child and can thus “look down” upon the child. as things
stand there is no default means to go the other way. yet the
relationship stands nonetheless. that’s why i tend to think ruby
probably has this information stored within it already anyway. so why
not make that a useful tool?

~transami

···

On Thu, 2002-07-04 at 18:16, Sean Russell wrote:

David Alan Black wrote:

REXML is specifically modeling the parent/child relationships of XML
in that class, though (I think). That’s different from a
language-level (I mean Ruby, not XML) description of one object as the
“parent” of another because the second object is created by a method
of the first object.

Yes. A REXML parent/child relationship has nothing to do with object
inheritance, but rather describes a contains/contained by relationship.

This is clouded by the fact that, in XML, elements can be seen to ‘inherit’
attributes from their parents – namespaces, in particular. Still, this is
more of a scoping issue than a direct inheritance issue.

Put another way, parent/child in REXML is a homonym to parent/child in Ruby
– same words, different meaning.

–

… “Even the Mongols rejected Communism… are we more dumb?”
<|> — Russian newspaper headline supporting Yeltzin’s 1996 campaign
/|\
/|

–
~transami

“They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.”
– Benjamin Franklin

19

Hi –

hi david,

yes the REXML isn’t really a good example, it was just a passing
thought. you may a good point. using a “Factory” would add a
consideration for self_parent’s use. but i don’t see how it could
possibly “constrain code and code growth significantly.” when one
designs a program it is exactly that: designed. no what i’m saying?
self_parent is just another tool.

I can’t argue with that last point, except to say I think there are
good tools and bad tools :slight_smile: But as for constraining code and code
growth: if different classes have hardcoded into them information
about how many method calls back certain objects were created, it
would make it essentially impossible to maintain and develop code
libraries – because every time you did something like my example with
Factory, other people’s code would break.

Of course, there are software updates which break old code. But
modifying an API is different from asking people to change
“self_parent” to “self_parent.self_parent” (for example) because
you’ve refactored a class.

David

···

On Fri, 5 Jul 2002, Tom Sawyer wrote:

–
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

20

hi james,

isnt this simply a matter of design? and one that is really inherit in
OOP? when i inherit a class or mixin a module, i am depending on certain
instances and methods to exist. that’s the nature of OO designs, in
order to achive code reuse. its a given that if you change one thing
somewhere you can break something that depends on it. that’s always a
consideration, self_parent or no.

Yes, if A creates B, and B changes its interface, A has a problem. That’s
expected, and why interfaces of base classes shouldn’t change without a
good reason. But, B should not break because A changes.

Suppose Ruby has self_parent, and people start using it. You write a class
that calls somebody else’s code. Your application works. Can you safely
change your code in the future? If the 3rd-party class is using self_parent
to call some of your object’s methods, then you might have an unplanned
dependency. If you are required to explicitly pass an object reference
to another class, then you know up front what the dependencies are.

Likewise, if I write code that inherits from a super class, the author of
that class knows that changes can break subclasses. But changes to a
subclass shouldn’t break the super class.

self_parent, as used in your example, means that the parent class must know
too much about how the other class is implemented. Dependencies are a part
of OO, but not something to be actively encouraged.

James

···

~transami