Operator Overloading <<

Discussion in 'Ruby' started by matt.hulse@gmail.com, Sep 30, 2005.

  1. Guest

    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
    , Sep 30, 2005
    #1
    1. Advertising

  2. On 9/29/05, <> 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 *
    * Alternate:
    Austin Ziegler, Sep 30, 2005
    #2
    1. Advertising

  3. Hi,

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


    ----
    Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
    Recursive Design Inc. -- <http://www.recursive.ca/>
    Raconteur -- <http://www.raconteur.info/>
    Bob Hutchison, Sep 30, 2005
    #3
  4. Austin Ziegler wrote:
    > On 9/29/05, <> 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 :)
    Robert Klemme, Sep 30, 2005
    #4
  5. On 9/30/05, Robert Klemme <> wrote:
    > Austin Ziegler wrote:
    > > On 9/29/05, <> 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.
    Brian Mitchell, Sep 30, 2005
    #5
  6. Operator Overriding (Re: Operator Overloading <<)

    Brian Mitchell wrote:
    > On 9/30/05, Robert Klemme <> wrote:
    >> Austin Ziegler wrote:
    >>> On 9/29/05, <> 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
    Robert Klemme, Sep 30, 2005
    #6
  7. On 9/30/05, Robert Klemme <> wrote:
    > Austin Ziegler wrote:
    > > On 9/29/05, <> 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 *
    * Alternate:
    Austin Ziegler, Sep 30, 2005
    #7
  8. On Sep 30, 2005, at 8:04 AM, Austin Ziegler wrote:
    > On 9/30/05, Robert Klemme <> 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/>
    Bob Hutchison, Sep 30, 2005
    #8
  9. On 9/30/05, Bob Hutchison <> wrote:
    > On Sep 30, 2005, at 8:04 AM, Austin Ziegler wrote:
    >> On 9/30/05, Robert Klemme <> 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 *
    * Alternate:
    Austin Ziegler, Sep 30, 2005
    #9
  10. 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/>
    Bob Hutchison, Sep 30, 2005
    #10
  11. On 9/30/05, Bob Hutchison <> 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.


    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
    --
    Austin Ziegler *
    * Alternate:
    Austin Ziegler, Sep 30, 2005
    #11
  12. Eric Mahurin Guest

    --- Austin Ziegler <> 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.


    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
    Eric Mahurin, Sep 30, 2005
    #12
  13. Matt Hulse Guest

    <<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
    Matt Hulse, Sep 30, 2005
    #13
  14. 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.
    >


    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

    ----
    Bob Hutchison -- blogs at <http://www.recursive.ca/hutch/>
    Recursive Design Inc. -- <http://www.recursive.ca/>
    Raconteur -- <http://www.raconteur.info/>
    Bob Hutchison, Sep 30, 2005
    #14
  15. 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.


    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
    James Edward Gray II, Sep 30, 2005
    #15
  16. 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 :) 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

    --
    David A. Black
    David A. Black, Sep 30, 2005
    #16
  17. Eric Mahurin Guest

    --- "David A. Black" <> wrote:

    > 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
    Eric Mahurin, Sep 30, 2005
    #17
  18. 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 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

    --
    David A. Black
    David A. Black, Sep 30, 2005
    #18
  19. > 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
    Daniel Amelang, Oct 1, 2005
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Smith
    Replies:
    2
    Views:
    414
    Ivan Vecerina
    Oct 6, 2004
  2. Replies:
    11
    Views:
    720
    James Kanze
    May 16, 2007
  3. hurcan solter
    Replies:
    3
    Views:
    714
    Cholo Lennon
    Aug 29, 2007
  4. Replies:
    11
    Views:
    545
  5. Replies:
    2
    Views:
    303
Loading...

Share This Page