protected members or explicit abstract classes?

Discussion in 'Ruby' started by aidy, Jul 21, 2008.

  1. aidy

    aidy Guest

    Hi,

    I am reading a book on Java OO.

    Could anyone tell me why Ruby does not include protected members nor
    explicit abstract classes?

    Thank You

    Aidy
    aidy, Jul 21, 2008
    #1
    1. Advertising

  2. aidy wrote:
    > Could anyone tell me why Ruby does not include protected members


    In ruby all instance variables are protected in the java sense (well, actually
    not quite since you can't access them from within another object of the same
    class).


    > nor explicit abstract classes?


    Well, I'd say modules qualify as explicitly abstract.

    HTH,
    Sebastian
    --
    Jabber:
    ICQ: 205544826
    Sebastian Hungerecker, Jul 21, 2008
    #2
    1. Advertising

  3. On Mon, Jul 21, 2008 at 11:39 AM, aidy <> wrote:
    > Hi,
    >


    Heya!

    > I am reading a book on Java OO.
    >


    If you want to read about OO design patterns in Ruby take a look at
    "Design Patterns in Ruby" by Russ Olsen
    (http://safari.oreilly.com/9780321490452).

    > explicit abstract classes?
    >


    Ruby is an interpreted language. There is no compile time check. AFAIK
    if you want to implement something like abstract classes, you can use
    the NotImplementedError exception:

    class Foo
    def bar
    throw NotImplementedError.new("Implement me!")
    end
    end

    --
    Fran Lebowitz - "Food is an important part of a balanced diet."
    Thomas Wieczorek, Jul 21, 2008
    #3
  4. aidy

    Robert Dober Guest

    Short answer:
    Because Ruby is not Java

    Long answer:
    Ruby just has a different way approaching object oriented
    programming. I believe that it is a more agile
    approach, and that abstract classes do not fit into Ruby's paradigm at all.

    Very long answer:
    As a matter of fact I believe that Ruby should not even have
    classes, class and type rhyme too strongly.
    I have developed different ways of doing object oriented
    development in Ruby (traits, prototypes, pushable behavior) all of
    them very slow, unfortunately. I really do not remember when I wanted
    an abstract class or a
    protected member last when developing in Ruby. I am still guilty of
    some code like "if String === s" but I
    hopefully one day will replace this with "if s.behaves_like? StringBehavior".
    Therefore the quintessence of my reply is, do Ruby, do ducktyping
    and ask yourself the question in some
    months time from now again!

    Cheers
    Robert

    --
    http://ruby-smalltalk.blogspot.com/

    There's no one thing that's true. It's all true.
    --
    Ernest Hemingway
    Robert Dober, Jul 21, 2008
    #4
  5. Hi --

    On Mon, 21 Jul 2008, Robert Dober wrote:

    > Short answer:
    > Because Ruby is not Java
    >
    > Long answer:
    > Ruby just has a different way approaching object oriented
    > programming. I believe that it is a more agile
    > approach, and that abstract classes do not fit into Ruby's paradigm at all.
    >
    > Very long answer:
    > As a matter of fact I believe that Ruby should not even have
    > classes, class and type rhyme too strongly.
    > I have developed different ways of doing object oriented
    > development in Ruby (traits, prototypes, pushable behavior) all of
    > them very slow, unfortunately. I really do not remember when I wanted
    > an abstract class or a
    > protected member last when developing in Ruby. I am still guilty of
    > some code like "if String === s" but I
    > hopefully one day will replace this with "if s.behaves_like? StringBehavior".


    You could do that with const_missing :) (I know there's more to it
    than that.)

    > Therefore the quintessence of my reply is, do Ruby, do ducktyping
    > and ask yourself the question in some
    > months time from now again!


    For true duck typing you would just do:

    s.the_method

    and live with the consequences :)


    David

    --
    Rails training from David A. Black and Ruby Power and Light:
    Intro to Ruby on Rails July 21-24 Edison, NJ
    * Advancing With Rails August 18-21 Edison, NJ
    * Co-taught by D.A. Black and Erik Kastner
    See http://www.rubypal.com for details and updates!
    David A. Black, Jul 21, 2008
    #5
  6. aidy

    Phlip Guest

    aidy wrote:

    > Could anyone tell me why Ruby does not include protected members nor
    > explicit abstract classes?


    Because Ruby makes unit testing easier than Java does. Tests provide positive
    reinforcement that your objects work correctly together. Static type checking
    (thru abstract base classes and protected members) only provides negative
    reinforcement that your objects might not work correctly together. Then, static
    checking impedes unit testing.

    http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html

    Positive reinforcement always works better - just ask a (non-Behaviorist) shrink.

    --
    Dr. Phlip
    Phlip, Jul 21, 2008
    #6
  7. aidy

    Robert Dober Guest

    On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <> wrote:
    > Hi --
    > For true duck typing you would just do:
    >
    > s.the_method

    In the general case thats seems clumsy to me, I'd rather check if a
    protocol is implemented. A very simple example is an IOArray I use to
    capture output, it mocks two file methods #puts and #<<.
    What would you prefer?

    raise Whatever unless o.replies_to?( :puts ) && o.replies_to?( :<< )

    raise Whatever unless o.implements_behavior? IOArray # but the name is bad

    Now imagine the protocol has five or even 10 methods?

    Maybe it might also be helpful to recall the definition of duck
    typing: "If it walks like a duck and talks like a talk...", this is
    about behavior and not about methods.
    My journey - that was long and would not have been so productive were
    it not for this list - has brought me to search out for new
    expressiveness of behavior and I pretty much like traits most right
    now. But I am still open to
    walk on ;).


    Cheers
    Robert
    --
    http://ruby-smalltalk.blogspot.com/

    There's no one thing that's true. It's all true.
    --
    Ernest Hemingway
    Robert Dober, Jul 21, 2008
    #7
  8. Hi --

    On Mon, 21 Jul 2008, Robert Dober wrote:

    > On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <> wrote:
    >> Hi --
    >> For true duck typing you would just do:
    >>
    >> s.the_method

    > In the general case thats seems clumsy to me, I'd rather check if a
    > protocol is implemented. A very simple example is an IOArray I use to
    > capture output, it mocks two file methods #puts and #<<.
    > What would you prefer?
    >
    > raise Whatever unless o.replies_to?( :puts ) && o.replies_to?( :<< )
    >
    > raise Whatever unless o.implements_behavior? IOArray # but the name is bad


    In general, I'd prefer:

    obj.<< # Rescue at this point, not before.

    It depends, though. I could imagine a situation where you really don't
    want to proceed until you've got at least some assurance that an
    object will respond as you want, because you're going to change some
    state in another object. I wouldn't like to see everything wrapped up
    in response checks.

    > Now imagine the protocol has five or even 10 methods?
    >
    > Maybe it might also be helpful to recall the definition of duck
    > typing: "If it walks like a duck and talks like a talk...", this is
    > about behavior and not about methods.


    Here's the thing, though. It is possible to do this:

    obj.some_method

    or this:

    if obj.respond_to?:)some_method)
    obj.some_method
    end

    or this:

    if obj.is_a?(Thing)
    obj.some_method
    end

    or this:

    if obj.implements_behavior?(Stuff)
    obj.some_method
    end

    etc. I've always understood duck typing to mean the first. I've also
    described the first as "hard" duck typing and the second as "soft"
    duck typing. Rick DeNatale makes a similar distinction between duck
    typing and "chicken typing".

    But in the end, it's got to be about what each of us likes to write in
    our programs. It's not like the one that gets called "duck typing" by
    the most people will suddenly be better than all the others in all
    circumstances :)


    David

    --
    Rails training from David A. Black and Ruby Power and Light:
    Intro to Ruby on Rails July 21-24 Edison, NJ
    * Advancing With Rails August 18-21 Edison, NJ
    * Co-taught by D.A. Black and Erik Kastner
    See http://www.rubypal.com for details and updates!
    David A. Black, Jul 21, 2008
    #8
  9. aidy

    Dean Wampler Guest

    [Note: parts of this message were removed to make it a legal post.]

    On Mon, Jul 21, 2008 at 5:09 PM, David A. Black <> wrote:

    > Hi --
    >
    > On Mon, 21 Jul 2008, Robert Dober wrote:
    >
    > On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <>
    >> wrote:
    >>
    >>> Hi --
    >>> For true duck typing you would just do:
    >>>
    >>> s.the_method
    >>>

    >> In the general case thats seems clumsy to me, I'd rather check if a
    >> protocol is implemented. A very simple example is an IOArray I use to
    >> capture output, it mocks two file methods #puts and #<<.
    >> What would you prefer?
    >> ...
    >>

    > It depends, though. I could imagine a situation where you really don't
    > want to proceed until you've got at least some assurance that an
    > object will respond as you want, because you're going to change some
    > state in another object. I wouldn't like to see everything wrapped up
    > in response checks....
    >


    I prefer the ruby way; let my automated tests confirm that the required
    methods are present when I include a module in another module, where the
    included module expects the including module to respond to a set of methods.
    Also, the tests document the behavior for the users!

    However, here's an idiom you could use to ensure that the methods "exist",
    at least at the time one module is included in other. Assume you have:

    module A
    include B
    ...
    end

    and assume that B expects A to respond to "doit". You can override
    Module#append_features:

    module B
    def append_features(including_module)
    unless including_module.respond_to?:)doit)
    raise ProtocolViolation.new("#{including_module} must respond to
    #doit")
    end
    super
    end
    ...
    end

    dean

    --
    Dean Wampler
    http://www.objectmentor.com
    http://www.aspectprogramming.com
    http://aquarium.rubyforge.org
    http://www.contract4j.org
    Dean Wampler, Jul 21, 2008
    #9
  10. HI --

    On Tue, 22 Jul 2008, Dean Wampler wrote:

    > On Mon, Jul 21, 2008 at 5:09 PM, David A. Black <> wrote:
    >
    >> Hi --
    >>
    >> On Mon, 21 Jul 2008, Robert Dober wrote:
    >>
    >> On Mon, Jul 21, 2008 at 2:37 PM, David A. Black <>
    >>> wrote:
    >>>
    >>>> Hi --
    >>>> For true duck typing you would just do:
    >>>>
    >>>> s.the_method
    >>>>
    >>> In the general case thats seems clumsy to me, I'd rather check if a
    >>> protocol is implemented. A very simple example is an IOArray I use to
    >>> capture output, it mocks two file methods #puts and #<<.
    >>> What would you prefer?
    >>> ...
    >>>

    >> It depends, though. I could imagine a situation where you really don't
    >> want to proceed until you've got at least some assurance that an
    >> object will respond as you want, because you're going to change some
    >> state in another object. I wouldn't like to see everything wrapped up
    >> in response checks....
    >>

    >
    > I prefer the ruby way;


    That's a bit of a conversation-stopper :)

    > let my automated tests confirm that the required methods are present
    > when I include a module in another module, where the included module
    > expects the including module to respond to a set of methods. Also,
    > the tests document the behavior for the users!


    Sure, no reason not to test everything. I think you may be
    misunderstanding my point, though (which certainly wasn't that one
    shouldn't write tests :) I'm very skeptical about the usefulness of
    respond_to? in cases where calling the method is going to raise an
    error anyway. I guess if it's a matter of this:

    raise unless obj.respond_to?:)meth)
    do_something_irreversible
    obj.meth # Disaster if we blow up here.

    then it makes sense at some level because you can't roll back. But I'm
    having trouble thinking of a real example.


    David

    --
    Rails training from David A. Black and Ruby Power and Light:
    Intro to Ruby on Rails July 21-24 Edison, NJ
    * Advancing With Rails August 18-21 Edison, NJ
    * Co-taught by D.A. Black and Erik Kastner
    See http://www.rubypal.com for details and updates!
    David A. Black, Jul 22, 2008
    #10
  11. aidy

    ara.t.howard Guest

    On Jul 21, 2008, at 3:39 AM, aidy wrote:

    > Hi,
    >
    > I am reading a book on Java OO.
    >
    > Could anyone tell me why Ruby does not include protected members nor
    > explicit abstract classes?
    >
    > Thank You
    >
    > Aidy



    as rubyists, we never protect our members.

    a @ http://codeforpeople.com/
    --
    we can deny everything, except that we have the possibility of being
    better. simply reflect on that.
    h.h. the 14th dalai lama
    ara.t.howard, Jul 22, 2008
    #11
  12. aidy

    Robert Dober Guest

    >
    > On Tue, 22 Jul 2008, Dean Wampler wrote:
    >


    >>
    >> I prefer the ruby way;

    >
    > That's a bit of a conversation-stopper :)


    Oh no problem, I'll teach him Ruby ;).
    >
    >> let my automated tests confirm that the required methods are present
    >> when I include a module in another module, where the included module
    >> expects the including module to respond to a set of methods. Also,
    >> the tests document the behavior for the users!


    That's exactly what I do in my *applications.
    However, I really try to be defensive when developing libraries or frameworks.
    David put it quite nicely, there are cases where I offer a service to
    a user. If it fails with a method missing deep inside the call stack
    the user just has to debug my framework or library to understand what
    happened (well of course it should be in the docs LOL).
    The least I want to tell him is:
    Pally, look this thingy of yours you passed into foo does not look
    like a bar, sure U know what UR doing?
    Now of course she knows exactly what to do ;).

    Again in general I agree, I will not check for protocols or methods in
    my standard application, that is what tests (or microtests ) are for.


    Cheers
    Robert
    Robert Dober, Jul 22, 2008
    #12
    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. Praveen
    Replies:
    1
    Views:
    361
    Woebegone
    Nov 21, 2003
  2. DaKoadMunky
    Replies:
    4
    Views:
    537
    Lee Weiner
    Apr 20, 2004
  3. Mr Dyl
    Replies:
    2
    Views:
    469
    Mr Dyl
    Dec 1, 2005
  4. Sideswipe
    Replies:
    6
    Views:
    365
    Daniel Pitts
    Sep 20, 2007
  5. Kevin Prichard
    Replies:
    11
    Views:
    397
    Richard Cornford
    Nov 29, 2005
Loading...

Share This Page