Operator Overloading <<

[matt.hulse]

Is there a way to overload '<<' in the Array class?

Or perhaps there's a better approach to my problem. I have a class
that inherits from Array. I want the user to be able to use my class
just like a standard array. However, I want to be able to force some
code to run every time a user of my class appends a new item. I was
able to overload the '+' operator to do this but it doesn't fit with
standard array usage.

Thanks in advance!

Matt
(e-mail address removed)

 

[Austin Ziegler]

Is there a way to overload '<<' in the Array class?

Or perhaps there's a better approach to my problem. I have a class
that inherits from Array. I want the user to be able to use my class
just like a standard array. However, I want to be able to force some
code to run every time a user of my class appends a new item. I was
able to overload the '+' operator to do this but it doesn't fit with
standard array usage.

It's generally not considered a good idea to overload. Consider using
Delegate instead.

-austin

 

[Bob Hutchison]

Hi,

Is there a way to overload '<<' in the Array class?

Or perhaps there's a better approach to my problem. I have a class
that inherits from Array. I want the user to be able to use my class
just like a standard array. However, I want to be able to force some
code to run every time a user of my class appends a new item. I was
able to overload the '+' operator to do this but it doesn't fit with
standard array usage.

I'm not sure what you mean by overloading. You don't mean like this?...

class MyArray < Array
def <<(v)
puts "before #{v}: #{self.inspect}"
super(v)
puts "after #{v}: #{self.inspect}"
return self
end
end

a = MyArray.new
a << 1 << 2 << 3
p a

Cheers,
Bob

 

[Robert Klemme]

It's generally not considered a good idea to overload. Consider using
Delegate instead.

Pardon me, but this is nonsense: Matt has *inherited* Array. Of course
you can argue about whether *that* is reasonable, but once you did that
providing your own implementation of a super class method in a derived
class is completely standard OO. There's even a keyword to support this
("super").

If you wanted to question the practice of inheriting classes like Array
and String then I'm completely with you. This doesn't make sense more
often that it does. But I know too little of this particular case to
further comment on that.

Kind regards

-r

 

[Brian Mitchell]

Pardon me, but this is nonsense: Matt has *inherited* Array. Of course
you can argue about whether *that* is reasonable, but once you did that
providing your own implementation of a super class method in a derived
class is completely standard OO. There's even a keyword to support this
("super").

If you wanted to question the practice of inheriting classes like Array
and String then I'm completely with you. This doesn't make sense more
often that it does. But I know too little of this particular case to
further comment on that.

Kind regards

-r

It seems like this thread ought to consider the differences between
overloading and overriding. They are most certainly not the same.

Brian.

 

[Robert Klemme]

It seems like this thread ought to consider the differences between
overloading and overriding. They are most certainly not the same.

True. We used the wrong term. But if I'm not mistaken everybody was
actually talking about overriding so far - even if they used the wrong
word. Thanks for reminding us!

Kind regards

robert

 

[Austin Ziegler]

Pardon me, but this is nonsense: Matt has *inherited* Array. Of course
you can argue about whether *that* is reasonable, but once you did that
providing your own implementation of a super class method in a derived
class is completely standard OO. There's even a keyword to support this
("super").

And all of that still works with Delegate. I know, because I *just*
did it for some code that won't see the light of day for a while.

If you wanted to question the practice of inheriting classes like Array
and String then I'm completely with you. This doesn't make sense more
often that it does. But I know too little of this particular case to
further comment on that.

That's really what I was trying to say here. Yes, the idea is *don't*
inherit from Array. You can't overload in Ruby, you can override and
you have to call super to make it work, or you have to call it
directly with aliasing.

-austin

 

[Bob Hutchison]

And all of that still works with Delegate. I know, because I *just*
did it for some code that won't see the light of day for a while.



That's really what I was trying to say here. Yes, the idea is *don't*
inherit from Array. You can't overload in Ruby, you can override and
you have to call super to make it work, or you have to call it
directly with aliasing.

Where do you stop? Why inherit at all? How do you decide?

[I sympathise with this, I've always preferred composition to
inheritance. Worse still, I went to the OOPSLA'87 (Orlando anyway,
think it was 1987) conference because I didn't 'get' OO and was
hoping to figure it out. I mentioned this to someone I was sitting
beside and was treated to a lesson over lunch (maybe breakfast, can't
remember). This person was David Unger, one of the key people
responsible for self and the alternate OO model, delegation/
prototype, to Ruby's class-based OO model. So I was indoctrinated
early by one of the best The "Treaty of Orlando" <http://
citeseer.ist.psu.edu/stein89shared.html> came out of that conference.]

Cheers,
Bob

 

[Austin Ziegler]

Where do you stop? Why inherit at all? How do you decide?

Sorry, but this really doesn't have anything to do with my statement.
One shouldn't inherit from Array, String, and Hash in Ruby because there
are certain things that Don't Work the way that you'd expect them to
because they are written in the C side.

In general, I don't have a problem with inheritance -- it should be used
smartly -- but in this specific case, inheriting from certain of Ruby's
core classes is enough of a problem that you do *not* want to do that.

-austin

 

[Bob Hutchison]

inheriting from certain of Ruby's
core classes is enough of a problem that you do *not* want to do that.

What classes are difficult? Seriously asked. It would be very useful
to know.

 

[Austin Ziegler]

What classes are difficult? Seriously asked. It would be very useful
to know.

Previously named: Array, Hash, and String are the most problematic. In
implementing PDF::Core versions of these types, I used Delegate. I
also did the same with Symbol.

I'd say that subclassing anything that is written in C is likely to be
difficult and have surprising results.

-austin

 

[Eric Mahurin]

Sorry, but this really doesn't have anything to do with my
statement.
One shouldn't inherit from Array, String, and Hash in Ruby
because there
are certain things that Don't Work the way that you'd expect
them to
because they are written in the C side.

In addition to this, I'd also say be very careful about
redefining methods in core classes. Same reason - they are
written in C. Many times the C code bypasses the standard
method call mechanism and calls other C code methods directly
so if you redefine you may not get what you want. An extreme
example is Regexp#=3D~. See what happens when you try to
override it - you'll get inconsistent results even if only ruby
code calls it.



=09
__________________________________=20
Yahoo! Mail - PC Magazine Editors' Choice 2005=20
http://mail.yahoo.com

 

[Matt Hulse]

<<Austin>>You can't overload in Ruby, you can override and you have to
call super to make it work, or you have to call it directly with
aliasing.

Yes, override is the term I should have used. Bob and Daniel, thanks
for the examples and Austin, thanks for the guidance in the right
direction. I will go learn about delegates and see how I fare. Aside
from being new to Ruby I'm still pretty new to programming in general.
(Just a couple of C++ classes under my belt. Enough to be dangerous
;-) ) But I am loving Ruby!!!

Are delegates common to all OO languages? I don't remember learning
about them in my C++ class.

Thanks again.

Matt

 

[Bob Hutchison]

Are delegates common to all OO languages? I don't remember learning
about them in my C++ class.

In class based languages like C++ and Ruby it is a technique (or
pattern). In delegate/prototype based languages (like self and
JavaScript) it is the mechanism used to implement inheritance.

You should be able to find some good examples in Ruby by googling
around a bit. One thing to read would be the Pragmatic Programmers
page: <http://www.rubycentral.com/book/lib_patterns.html>

Cheers,
Bob

 

[James Edward Gray II]

Are delegates common to all OO languages? I don't remember learning
about them in my C++ class.

Delegation is a design pattern and in that sense, yes, it's common to
most languages:

http://en.wikipedia.org/wiki/Delegation_(programming)

In Ruby, we have two standard libraries that cover delegation. I
just finished documenting them and am trying to get them up on ruby-
doc.org, but until then, here's some sample code from the docs of
delegate.rb:

#
# The primary interface to this library. Use to setup delegation
when defining
# your class.
#
# class MyClass < DelegateClass( ClassToDelegateTo ) # Step 1
# def initiaize
# super(obj_of_ClassToDelegateTo) # Step 2
# end
# end
#

and

#
# === DelegateClass()
#
# Here's a sample of use from <i>tempfile.rb</i>.
#
# A _Tempfile_ object is really just a _File_ object with a few
special rules
# about storage location and/or when the File should be deleted.
That makes for
# an almost textbook perfect example of how to use delegation.
#
# class Tempfile < DelegateClass(File)
# # constant and class member data initialization...
#
# def initialize(basename, tmpdir=Dir::tmpdir)
# # build up file path/name in var tmpname...
#
# @tmpfile = File.open(tmpname, File::RDWR|File::CREAT|
File::EXCL, 0600)
#
# # ...
#
# super(@tmpfile)
#
# # below this point, all methods of File are supported...
# end
#
# # ...
# end
#

Hope that helps.

James Edward Gray II

 

[David A. Black]

Hi --

Where do you stop? Why inherit at all? How do you decide?

[I sympathise with this, I've always preferred composition to inheritance.
Worse still, I went to the OOPSLA'87 (Orlando anyway, think it was 1987)
conference because I didn't 'get' OO and was hoping to figure it out. I
mentioned this to someone I was sitting beside and was treated to a lesson
over lunch (maybe breakfast, can't remember). This person was David Unger,
one of the key people responsible for self and the alternate OO model,
delegation/prototype, to Ruby's class-based OO model. So I was indoctrinated
early by one of the best The "Treaty of Orlando" <http://
citeseer.ist.psu.edu/stein89shared.html> came out of that conference.]

I sometimes wonder how class-based Ruby's model is. Or maybe it's a
hybrid. I don't know any purely prototyped languages, so I can't
compare directly, but I always think of a class in Ruby as a mechanism
for bootstrapping objects into object-space -- at which point the
objects have nothing further to do with the class, except that some
subset of the class's instance methods may continue to serve as a
subset of the methods of the object. (But it never has to; that's
just a convenient default.)

It's the old "class != type in Ruby" thing. I wonder whether Ruby's
potential to be regarded as a prototyped language simply has yet to be
fully explored.

module Kernel
undef :kind_of?, :is_a? # maybe a few others
end

would be an interesting experiment


David

 

[Eric Mahurin]

Hi --
=20
On Fri, 30 Sep 2005, Bob Hutchison wrote:
=20

Where do you stop? Why inherit at all? How do you decide?

[I sympathise with this, I've always preferred composition to inheritance.=20
Worse still, I went to the OOPSLA'87 (Orlando anyway, think it was 1987)=20
conference because I didn't 'get' OO and was hoping to figure it out. I=20
mentioned this to someone I was sitting beside and was treated to a lesson=20
over lunch (maybe breakfast, can't remember). This person was David Unger,=20
one of the key people responsible for self and the alternate OO model,=20
delegation/prototype, to Ruby's class-based OO model. So I was indoctrinated=20
early by one of the best The "Treaty of Orlando" <http://=20
citeseer.ist.psu.edu/stein89shared.html> came out of that

conference.]
=20
I sometimes wonder how class-based Ruby's model is. Or maybe
it's a
hybrid. I don't know any purely prototyped languages, so I
can't
compare directly, but I always think of a class in Ruby as a
mechanism
for bootstrapping objects into object-space -- at which point
the
objects have nothing further to do with the class, except
that some
subset of the class's instance methods may continue to serve
as a
subset of the methods of the object. (But it never has to;
that's
just a convenient default.)
=20
It's the old "class !=3D type in Ruby" thing. I wonder whether
Ruby's
potential to be regarded as a prototyped language simply has
yet to be
fully explored.
=20
module Kernel
undef :kind_of?, :is_a? # maybe a few others
end

It looks like ruby does prototyping just fine since each object
can have its own meta class:

class Object
def meta_class
class << self;self;end
end
end

a =3D Object.new
a.meta_class.class_eval { def foo;"a";end }
b =3D a.clone
p a.foo # =3D> "a"
p b.foo # =3D> "a"

b.meta_class.class_eval { def foo;"b";end }
p a.foo # =3D> "a"
p b.foo # =3D> "b"

a.meta_class.class_eval { def foo;"A";end }
p a.foo # =3D> "A"
p b.foo # =3D> "b"

I'm not sure how memory efficient this would be compared to a
pure prototyping language though. Not sure if initially b
(directly from a.clone) shares the "foo" definition or not.


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20

 

[David A. Black]

Hi --

It looks like ruby does prototyping just fine since each object
can have its own meta class:

class Object
def meta_class
class << self;self;end
end
end

Yes I know -- see http://www.rcrchive.net/rcr/show/231 That's
what I mean: Ruby objects have a class but they also have their own
life beyond their birth-class.


David

 

[Daniel Amelang]

Ruby objects have a class but they also have their own

life beyond their birth-class.

Unlike Slashdot-reader objects, who never even move out of the
basement of their birth-class.

C'mon, it's friday!

Dan Amelang