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
matt.hulse@gmail.com
It's generally not considered a good idea to overload. Consider using
Delegate instead.
-austin
On 9/29/05, matt.hulse@gmail.com <matt.hulse@gmail.com> wrote:
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.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
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
On Sep 29, 2005, at 7:11 PM, matt.hulse@gmail.com wrote:
Thanks in advance!
Matt
matt.hulse@gmail.com
----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>
Austin Ziegler wrote:
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.
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 
On 9/29/05, matt.hulse@gmail.com <matt.hulse@gmail.com> wrote:
<<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
It seems like this thread ought to consider the differences between
overloading and overriding. They are most certainly not the same.
Brian.
On 9/30/05, Robert Klemme <bob.news@gmx.net> wrote:
Austin Ziegler wrote:
> On 9/29/05, matt.hulse@gmail.com <matt.hulse@gmail.com> wrote:
>> 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.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
Austin Ziegler wrote:
>> 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.
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
On 9/30/05, Robert Klemme <bob.news@gmx.net> wrote:
> On 9/29/05, matt.hulse@gmail.com <matt.hulse@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
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
On Sep 30, 2005, at 10:56 AM, Matt Hulse wrote:
Are delegates common to all OO languages? I don't remember learning
about them in my C++ class.
----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>
Delegation is a design pattern and in that sense, yes, it's common to most languages:
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:
On Sep 30, 2005, at 9:56 AM, Matt Hulse wrote:
Are delegates common to all OO languages? I don't remember learning
about them in my C++ class.
#
# 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
Brian Mitchell wrote:
On 9/30/05, Robert Klemme <bob.news@gmx.net> wrote:
Austin Ziegler wrote:
On 9/29/05, matt.hulse@gmail.com <matt.hulse@gmail.com> wrote:
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.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.
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
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
On Sep 30, 2005, at 8:04 AM, Austin Ziegler wrote:
On 9/30/05, Robert Klemme <bob.news@gmx.net> wrote:
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.
----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>
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
On 9/30/05, Bob Hutchison <hutch@recursive.ca> wrote:
On Sep 30, 2005, at 8:04 AM, Austin Ziegler wrote:
On 9/30/05, Robert Klemme <bob.news@gmx.net> wrote:
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.Where do you stop? Why inherit at all? How do you decide?
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
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
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
On Fri, 30 Sep 2005, Bob Hutchison wrote:
--
David A. Black
dblack@wobblini.net
What classes are difficult? Seriously asked. It would be very useful to know.
On Sep 30, 2005, at 9:48 AM, Austin Ziegler wrote:
inheriting from certain of Ruby's
core classes is enough of a problem that you do *not* want to do that.
----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>
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#=~. See what happens when you try to
override it - you'll get inconsistent results even if only ruby
code calls it.
--- Austin Ziegler <halostatue@gmail.com> wrote:
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.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
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 = Object.new
a.meta_class.class_eval { def foo;"a";end }
b = a.clone
p a.foo # => "a"
p b.foo # => "a"
b.meta_class.class_eval { def foo;"b";end }
p a.foo # => "a"
p b.foo # => "b"
a.meta_class.class_eval { def foo;"A";end }
p a.foo # => "A"
p b.foo # => "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.
--- "David A. Black" <dblack@wobblini.net> wrote:
Hi --
On Fri, 30 Sep 2005, Bob Hutchison wrote:
> 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
<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
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
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
On 9/30/05, Bob Hutchison <hutch@recursive.ca> wrote:
On Sep 30, 2005, at 9:48 AM, Austin Ziegler wrote:
> 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 * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Hi --
On Sat, 1 Oct 2005, Eric Mahurin wrote:
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 RCR 231: Kernel#singleton_class That's
what I mean: Ruby objects have a class but they also have their own
life beyond their birth-class.
David
--
David A. Black
dblack@wobblini.net
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