Self_parent

ruby-talk
21

Do you really need a parent class? If you can get by with a module,
you can do this:

module A
def aa
puts “Aaa”
end
def cc
puts “Acc”
end
class B
include A
def bb
puts “Bbb”
end
def aa
puts “Baa”
end
end
end

b = A::B.new
b.aa
b.bb
b.cc

···

On Friday 05 July 2002 07:37 am, Tom Sawyer wrote:

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

–
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE

22

In ten years of professional software development, a good chunk of
it doing OO, I have never had a contained class (the child) call a
method in the containing class (the parent).

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.07.05 at 18.10.13

···

On Sat, 6 Jul 2002 03:32:11 +0900, Tom Sawyer wrote:

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?
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.

23

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?

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.

And I guess that even somewhere' is very distant from almost
anywhere’, isn’t it?

“hello, world” is not a good example as it is an utterly useless
program.

Every time you create a string, you are creating an object. Do you
want all those strings (and numbers and everything else) implicitly
coupled with the context they are created in? In other words, do you
want not to see, when reading code, what is coupled to what?

useful programs are much more complex, where
self passing is much more likely and useful.

Just issued this:

bard@prism:~/src/rpkg$ find . -name ‘*.rb’ | xargs grep ‘new(.self.)’

No result. :slight_smile:

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

Take one of those scripts and count the objects (including every
number, string, range, array… remember, everything is an object) and
compare the number of those where you needed to pass self to those
where you needed not. Well, that’s `general’. :slight_smile:

Massimiliano

···

On Sat, Jul 06, 2002 at 03:32:11AM +0900, Tom Sawyer wrote:

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

24

dirk, thank you for the comprehensive investigation into the self_parent
concept. it was very enlightening.

after some additional thought, and still not being satisifed with any
implementation i have yet divised for my problem, i have come to realize
more clearly what is i am trying to accomplish.

essentially what i am trying to create are non-bound, or open, Proc
objects, in contrast to the type of Proc objects we can create now,
which are bound to the local variables at the time of creation. I want
Proc objects that get bound at the time of calling:

class A
def initialize(x)
x.call
end
def display
puts ‘hello’
end
end

class B
def initialize(x)
x.call
end
def display
puts ‘goodbye’
end
end

x = OpenProc { display }

A.new(x) → hello
B.new(x) → goodbye

in this way an object can, in effect, ask another object what it should
do. and that is what i was accomplishing, albiet in a lame way, by
passing self (and wanting self_parent for).

so, is there any way to readily accomplish this in ruby?

~transami

···

On Mon, 2002-07-08 at 05:28, Dirk Detering wrote:

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

–
~transami

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

25

well what would be a good name if not self_parent? i see how the parent
part might imply the superclass. at first i was just using the word
“parent” but that has the same problem and also parent is a common
symbol used in other programs, so i used the prefix self_ so as not to
cause code breaking. how about self_creator? don’t really like the
sound of that. self_instantiator? what would you call this exact
relationship anyway? is ther an academic/technical term for it?

~transami

···

On Thu, 2002-07-04 at 19:03, David Alan Black wrote:

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

–
~transami

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

26

what if it had a method argument to identify the class name:

self_ancestor(Class)

or the like? in this way you could move as far up as you needed without
breaking code under refactorization. of course, precedence would have to
be given to the first match in the case of a parent creating an instance
of itself.

~tom

···

On Thu, 2002-07-04 at 19:18, David Alan Black wrote:

Hi –

On Fri, 5 Jul 2002, Tom Sawyer wrote:

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

–
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

27

I’m sure Ruby could allow this to happen, but except in the case of
XML parsing, I’m not sure I see the utility – or how it would work
– except as information.

In XML parsing, it’s a relatively safe thing to do because the child
elements will be of the same base class as the parent elements.

What good would it do for Net::POP to know that it has been
instantiated by a particular class? Unless Net::POP has some
relationship other than ‘created by’ with that class, then Net::POP
can’t actually use any of the methods or data that the creating
class offers.

IMO, this makes for too tight a coupling between unrelated classes,
ultimately.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.07.05 at 08.37.30

···

On Fri, 5 Jul 2002 10:04:39 +0900, Tom Sawyer wrote:

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?

28

In ten years of professional software development, a good chunk of
it doing OO, I have never had a contained class (the child) call a
method in the containing class (the parent).

I can’t think of an instance where I have either. I’ve passed self
before, but I can’t ever remember thinking it was a good idea.

···

=====

Use your computer to help find a cure for cancer: http://members.ud.com/projects/cancer/

Yahoo IM: michael_s_campbell

Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free

29

One way could be to use eval with a binding coming from the object,
e.g.:

class A
def get_binding
return binding
end

def display
puts ‘hello’
end
end

a = A.new
eval(“display”, a.get_binding)

But eval is evil. :slight_smile:

Another is what I think is called a `singleton method’:

a = A.new
def a.do_this
display
end
a.do_this

However, it would be nice if Proc objects could refer not necessarily
to the context where they were created, but to an arbitrary one. But
I suspect this would pose many difficulties.

Massimiliano

···

On Tue, Jul 09, 2002 at 03:51:24PM +0900, Tom Sawyer wrote:

class A
def initialize(x)
x.call
end
def display
puts ‘hello’
end
end

class B
def initialize(x)
x.call
end
def display
puts ‘goodbye’
end
end

x = OpenProc { display }

A.new(x) → hello
B.new(x) → goodbye

in this way an object can, in effect, ask another object what it should
do. and that is what i was accomplishing, albiet in a lame way, by
passing self (and wanting self_parent for).

so, is there any way to readily accomplish this in ruby?

30

You said you didn’t want to pass self, but given your example
this is what I would do:

class A
def initialize(k)
k.call(self)
end
def display
puts ‘hello’
end
end

class B
def initialize(j)
j.call(self)
end
def display
puts ‘goodbye’
end
end

y = lambda { |z| z.display }

A.new(y)
B.new(y)

Is there a slightly more detailed example that might better illustrate
what you’re trying to do?

– Dossy

···

On 2002.07.09, Tom Sawyer transami@transami.net wrote:

essentially what i am trying to create are non-bound, or open, Proc
objects, in contrast to the type of Proc objects we can create now,
which are bound to the local variables at the time of creation. I want
Proc objects that get bound at the time of calling:

class A
def initialize(x)
x.call
end
def display
puts ‘hello’
end
end

class B
def initialize(x)
x.call
end
def display
puts ‘goodbye’
end
end

x = OpenProc { display }

A.new(x) → hello
B.new(x) → goodbye

in this way an object can, in effect, ask another object what it should
do. and that is what i was accomplishing, albiet in a lame way, by
passing self (and wanting self_parent for).

so, is there any way to readily accomplish this in ruby?

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

31

class A
def initialize(x)
x.call
end
def display
puts ‘hello’
end
end

class B
def initialize(x)
x.call
end
def display
puts ‘goodbye’
end
end

x = OpenProc { display }

A.new(x) → hello
B.new(x) → goodbye

What else would OpenProc do? Why wouldn’t you do

class ScriptMe
def initialize( *x)
x.each{ |m|
self.send( m )
}
end

def display
puts ‘hello’
end
end

x = “display”

ScriptMe.new( x ) → hello

Or,

class OpenProc
attr_reader :proc, :script
def initialize( prk, skrpt )
@prok = prk
@script = skrpt
end
end

class ScriptMe
def initialize( op )
op.script.each{ |m|
self.send( m )
}
# do something with op.prok if need be …
end

def display
  puts 'hello'
end

end

x = OpenProc( proc{ puts “Hi!”}, “display” }
ScriptMe.new( x ) → hello

James

32

Hi –

···

On Fri, 5 Jul 2002, Tom Sawyer wrote:

what if it had a method argument to identify the class name:

self_ancestor(Class)

or the like? in this way you could move as far up as you needed without
breaking code under refactorization. of course, precedence would have to
be given to the first match in the case of a parent creating an instance
of itself.

If you keep at it, you might come full circle to the idea of passing
self as an argument :slight_smile: That’s the thing – I think as you examine the
problem with this idiom, you’ll end up finding other, more economical
ways to do the same kinds of things.

David

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

33

Has no one around here ever implemented the Visitor pattern!?

– Dossy

···

On 2002.07.06, Michael Campbell michael_s_campbell@yahoo.com wrote:

In ten years of professional software development, a good chunk of
it doing OO, I have never had a contained class (the child) call a
method in the containing class (the parent).

I can’t think of an instance where I have either. I’ve passed self
before, but I can’t ever remember thinking it was a good idea.

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

34

okay, i grant you i write code very differently then most others. at
least that has been my experience. i gerneally tend to hack something
out and then go over it and over and over it again trying to reduce
every little ounce of code reuse out of it that i can. i think if you
saw some on my work you’d be very suprised at how little code there is
and yet how much it does. so, when you appoach things in this way and
you have a class inheritiing a class inherting a class and so on and
those classes create other classes, to seperate logic from interface,
for example, it has been my experience that child classes need to “talk”
to their parents.

i can provide some examples, but it won’t be a tiny piece of code to
easily paste in an email.

and i think Michael, here, makes a good point: “I’ve passed self
before, but I can’t ever remember thinking it was a good idea.”

that’s really where i’m coming from too. for i don’t feel comfortable
with passing self really. so either i’m not writing my code in the best
manner or there really is a good reason to have this connection between
the container and contained. adn yet i’ve i gone over some of my code
angain and again. i it always seems the most effective means: passing
self.

perhaps i should just feel comfortable with passing self. that’s fine.
i’m not trying to push this or anything. i was curious to see what
others thought. really, this conversation has me wondering what others
might thing of my code.

~transami

···

On Fri, 2002-07-05 at 16:35, Michael Campbell wrote:

In ten years of professional software development, a good chunk of
it doing OO, I have never had a contained class (the child) call a
method in the containing class (the parent).

I can’t think of an instance where I have either. I’ve passed self
before, but I can’t ever remember thinking it was a good idea.

=====

Use your computer to help find a cure for cancer: http://members.ud.com/projects/cancer/

Yahoo IM: michael_s_campbell

Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

–
~transami

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

35

I think, you can easily write something like this
to implement automatic references to parent objects:

module CreatedObject
attr_accessor :creator
end

class Object
def create (klass, *args)
klass.create_new (self, *args)
end
end

class Class
def create_new (creator, *args)
obj = new *args
obj.extend CreatedObject
obj.creator = creator
obj
end
end

class B
def child
@a = create String
end
end

b = B.new
p b.child.creator

Maybe it is better to protect the access to creator
or even make creator a constant.
It would be better, to overload new, but there is no way to
get the calling object like you can get the execution stack
in Kernel.caller.
IMHO this would be a useful feature as it is already implemented
in some way.

So refering to your case of Procs you can write 'p = create Proc {…}'
and define something like call_proc in Object, which calls the Proc
in the objects context.

36

okay, i grant you i write code very differently then most others. at
least that has been my experience. i gerneally tend to hack something
out and then go over it and over and over it again trying to reduce
every little ounce of code reuse out of it that i can. i think if you
saw some on my work you’d be very suprised at how little code there is
and yet how much it does. so, when you appoach things in this way and
you have a class inheritiing a class inherting a class and so on and
those classes create other classes, to seperate logic from interface,
for example, it has been my experience that child classes need to “talk”
to their parents.

i can provide some examples, but it won’t be a tiny piece of code to
easily paste in an email.

Dosen’t sound like it’s reduced very far.

and i think Michael, here, makes a good point: “I’ve passed self
before, but I can’t ever remember thinking it was a good idea.”

And I asked: Do people never use the Visitor pattern?

that’s really where i’m coming from too. for i don’t feel comfortable
with passing self really. so either i’m not writing my code in the best
manner or there really is a good reason to have this connection between
the container and contained. adn yet i’ve i gone over some of my code
angain and again. i it always seems the most effective means: passing
self.

perhaps i should just feel comfortable with passing self. that’s fine.
i’m not trying to push this or anything. i was curious to see what
others thought. really, this conversation has me wondering what others
might thing of my code.

I know two things:

  1. Inheriting methods from your parent is good.

  2. Needing to know what the class of your parent is a coding smell.
    Especially if you are using multiple inheritance.

– Dossy

···

On 2002.07.06, Tom Sawyer transami@transami.net wrote:

–
Dossy Shiobara mail: dossy@panoptic.com
Panoptic Computer Network web: http://www.panoptic.com/
“He realized the fastest way to change is to laugh at your own
folly – then you can let go and quickly move on.” (p. 70)

37

Has no one around here ever implemented the Visitor pattern!?

Haven’t had a need to as yet for what I’ve done.

···

=====

Use your computer to help find a cure for cancer: http://members.ud.com/projects/cancer/

Yahoo IM: michael_s_campbell

Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free

38

Dosen’t sound like it’s reduced very far.

now you’ve asked for it:

Zen Accounting - ZenCustomer

Copyright (c)2002 Thomas Sawyer, All Rights Reserved

require ‘zencustomer_html’
require ‘zenrecord’
require ‘zenaddress’
require ‘zenphone’
require ‘zenbond’
require ‘zennote’
require ‘zenurl’

module ZenAcct

class ZenCustomer < ZenRecord

def initialize
  super('CUSTOMER', 'c')
  # subrecords 
  @addresses = ZenAddress.new(self)
  @phones = ZenPhone.new(self)
  @bonds = ZenBond.new(self)
  @notes = ZenNote.new(self)
  @urls = ZenURL.new(self)
end
··· 

def action
  super
  @addresses.action(@act)
  @phones.action(@act)
  @bonds.action(@act)
  @notes.action(@act)
  @urls.action(@act)
end

# Display the customer edit html
def display
  @html = ZenCustomer_HTML.new(self)
  $cgi.out { @html.html_page(@title, 'com') }
end

#
def load_dbi
  super
  @addresses.load_dbi
  @phones.load_dbi
  @bonds.load_dbi
  @notes.load_dbi
  @urls.load_dbi
end

#
def references
  ref = super
  if @edit_new
    ref.update(@addresses.references)
    ref.update(@phones.references)
    ref.update(@bonds.references)
    ref.update(@notes.references)
    ref.update(@urls.references)
  end
  return ref
end

#
def sql_taxes
  sql = "SELECT * FROM taxes WHERE partner='c';"
  rec = $dbi.connection.select_all(sql)
  return rec
end

#
def sql_terms
  sql = "SELECT * FROM terms WHERE partner='c';"
  rec = $dbi.connection.select_all(sql)
  return rec
end

end # ZenCustomer

end # ZenAcct

39

Hi –

I know two things:

  1. Inheriting methods from your parent is good.

  2. Needing to know what the class of your parent is a coding smell.
    Especially if you are using multiple inheritance.

Also (again, the terminological problem), the thing we’re talking
about here isn’t a traditional OO inheritance or parent/child
relationship, but rather the matter of an object knowing what the
value of “self” was at the time that it was instantiated. I’ve found
the thread interesting, though I’m still not convinced that this
notion has a place in good Ruby code design.

David

···

On Sat, 6 Jul 2002, Dossy wrote:

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

40

We have, but don’t necessarily think it’s the best of both worlds.

Like many of the patterns in the GOF book, it comes across as more of
a reaction to language limitations than a first-class idea. The
problem they were trying to solve is the lack of multiple dispatching
and open classes in C++.

Since Ruby has open classes (and iterators), the motivation for using
the cumbersome double-dispatching of the Visitor pattern is largely
absent.

···

On Saturday 06 July 2002 06:32 am, Dossy wrote:

and i think Michael, here, makes a good point: “I’ve passed self
before, but I can’t ever remember thinking it was a good idea.”

And I asked: Do people never use the Visitor pattern?

–
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE