Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Ruby (http://www.velocityreviews.com/forums/f66-ruby.html)
-   -   Operator Overloading << (http://www.velocityreviews.com/forums/t824836-operator-overloading.html)

matt.hulse@gmail.com 09-29-2005 11:09 PM

Operator Overloading <<
 
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


Austin Ziegler 09-29-2005 11:15 PM

Re: Operator Overloading <<
 
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.

-austin
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca



Bob Hutchison 09-30-2005 12:20 AM

Re: Operator Overloading <<
 
Hi,

On Sep 29, 2005, at 7:11 PM, 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.


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
> 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/>





Robert Klemme 09-30-2005 07:48 AM

Re: Operator Overloading <<
 
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 :-)


Brian Mitchell 09-30-2005 07:56 AM

Re: Operator Overloading <<
 
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.

Brian.



Robert Klemme 09-30-2005 08:25 AM

Operator Overriding (Re: Operator Overloading <<)
 
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


Austin Ziegler 09-30-2005 12:04 PM

Re: Operator Overloading <<
 
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").


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 * halostatue@gmail.com
* Alternate: austin@halostatue.ca



Bob Hutchison 09-30-2005 01:24 PM

Re: Operator Overloading <<
 

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?

[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/>





Austin Ziegler 09-30-2005 01:48 PM

Re: Operator Overloading <<
 
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?


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 * halostatue@gmail.com
* Alternate: austin@halostatue.ca



Bob Hutchison 09-30-2005 01:51 PM

Re: Operator Overloading <<
 

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/>






All times are GMT. The time now is 04:32 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.