Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Operator Overloading <<

Reply
Thread Tools

Operator Overloading <<

 
 
matt.hulse@gmail.com
Guest
Posts: n/a
 
      09-29-2005
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
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
 
 
 
Austin Ziegler
Guest
Posts: n/a
 
      09-29-2005
On 9/29/05, (E-Mail Removed) <(E-Mail Removed)> 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.

-austin
--
Austin Ziegler * (E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
 
 
 
Bob Hutchison
Guest
Posts: n/a
 
      09-30-2005
Hi,

On Sep 29, 2005, at 7:11 PM, (E-Mail Removed) 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.


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

>
> Thanks in advance!
>
> Matt
> (E-Mail Removed)
>
>
>


----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>




 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      09-30-2005
Austin Ziegler wrote:
> On 9/29/05, (E-Mail Removed) <(E-Mail Removed)> 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

 
Reply With Quote
 
Brian Mitchell
Guest
Posts: n/a
 
      09-30-2005
On 9/30/05, Robert Klemme <(E-Mail Removed)> wrote:
> Austin Ziegler wrote:
> > On 9/29/05, (E-Mail Removed) <(E-Mail Removed)> 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.

Brian.


 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      09-30-2005
Brian Mitchell wrote:
> On 9/30/05, Robert Klemme <(E-Mail Removed)> wrote:
>> Austin Ziegler wrote:
>>> On 9/29/05, (E-Mail Removed) <(E-Mail Removed)> 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

 
Reply With Quote
 
Austin Ziegler
Guest
Posts: n/a
 
      09-30-2005
On 9/30/05, Robert Klemme <(E-Mail Removed)> wrote:
> Austin Ziegler wrote:
> > On 9/29/05, (E-Mail Removed) <(E-Mail Removed)> 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
--
Austin Ziegler * (E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
Bob Hutchison
Guest
Posts: n/a
 
      09-30-2005

On Sep 30, 2005, at 8:04 AM, Austin Ziegler wrote:
> On 9/30/05, Robert Klemme <(E-Mail Removed)> 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?

[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

----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>




 
Reply With Quote
 
Austin Ziegler
Guest
Posts: n/a
 
      09-30-2005
On 9/30/05, Bob Hutchison <(E-Mail Removed)> wrote:
> On Sep 30, 2005, at 8:04 AM, Austin Ziegler wrote:
>> On 9/30/05, Robert Klemme <(E-Mail Removed)> 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?


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
--
Austin Ziegler * (E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
Bob Hutchison
Guest
Posts: n/a
 
      09-30-2005

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.

----
Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
Recursive Design Inc. -- <http://www.recursive.ca/>
Raconteur -- <http://www.raconteur.info/>




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
overloading operator->*() and operator->() gob00st@googlemail.com C++ 2 02-21-2009 04:26 AM
overloading operator->*() and operator->() gob00st@googlemail.com C++ 11 02-20-2009 08:52 PM
user defined conversion operator or operator overloading? hurcan solter C++ 3 08-29-2007 07:39 PM
Why is overloading operator. (member operator) forbidden? dascandy@gmail.com C++ 11 05-16-2007 07:54 PM
Operator overloading on "default" operator John Smith C++ 2 10-06-2004 10:22 AM



Advertisments