Object Orientation

Discussion in 'Ruby' started by Krekna Mektek, Oct 5, 2005.

  1. Hi again,

    Can someone point me to a not-too-long introduction of howto to model
    objects in Ruby OO?
    I am reading a OO book, but I already want to try to OO my actual
    procedural-programmed script.

    Thanx.
     
    Krekna Mektek, Oct 5, 2005
    #1
    1. Advertising

  2. Krekna Mektek wrote:
    > Hi again,
    >
    > Can someone point me to a not-too-long introduction of howto to model
    > objects in Ruby OO?
    > I am reading a OO book, but I already want to try to OO my actual
    > procedural-programmed script.


    Basically, it's

    class YourClass < AnotherClass
    attr_accessor :name

    def a_method(foo, bar)
    foo + bar
    end
    end


    A small collection...

    http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html
    http://pine.fm/LearnToProgram/?Chapter=09
    http://www.rubygarden.org/ruby?ObjectOriented

    And, for the fun part:
    http://poignantguide.net/ruby/

    Kind regards

    robert
     
    Robert Klemme, Oct 5, 2005
    #2
    1. Advertising

  3. Krekna Mektek

    Dave Burt Guest

    Robert Klemme wrote:
    > Krekna Mektek wrote:
    >> Hi again,
    >>
    >> Can someone point me to a not-too-long introduction of howto to model
    >> objects in Ruby OO?
    >> I am reading a OO book, but I already want to try to OO my actual
    >> procedural-programmed script.

    >
    > Basically, it's
    >
    > class YourClass < AnotherClass
    > ...
    >
    > http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html
    > http://pine.fm/LearnToProgram/?Chapter=09
    > http://www.rubygarden.org/ruby?ObjectOriented
    >
    > And, for the fun part:
    > http://poignantguide.net/ruby/


    There's also this one, which isn't particularly short, but it's like a
    conversation describing Ruby's OO.
    Brian Marick's _A Little Ruby, A Lot of Objects_:
    http://www.visibleworkings.com/little-ruby/

    Cheers,
    Dave
     
    Dave Burt, Oct 5, 2005
    #3
  4. Wow, thanx, these, especially the Little Ruby, A Lot of Objects draft
    book, are nice links.


    By the way, why are methods not named following the lowercaseUppercase
    convention, as in Java?
    This way I can see more directly that something is a method, and not
    an instance variable.

    I'd like to do it that way, but am not sure if this is against some
    Ruby philosophy..

    Krekna



    2005/10/5, Dave Burt <>:
    > Robert Klemme wrote:
    > > Krekna Mektek wrote:
    > >> Hi again,
    > >>
    > >> Can someone point me to a not-too-long introduction of howto to model
    > >> objects in Ruby OO?
    > >> I am reading a OO book, but I already want to try to OO my actual
    > >> procedural-programmed script.

    > >
    > > Basically, it's
    > >
    > > class YourClass < AnotherClass
    > > ...
    > >
    > > http://www.ruby-doc.org/docs/ProgrammingRuby/html/tut_classes.html
    > > http://pine.fm/LearnToProgram/?Chapter=3D09
    > > http://www.rubygarden.org/ruby?ObjectOriented
    > >
    > > And, for the fun part:
    > > http://poignantguide.net/ruby/

    >
    > There's also this one, which isn't particularly short, but it's like a
    > conversation describing Ruby's OO.
    > Brian Marick's _A Little Ruby, A Lot of Objects_:
    > http://www.visibleworkings.com/little-ruby/
    >
    > Cheers,
    > Dave
    >
    >
    >
    >
     
    Krekna Mektek, Oct 5, 2005
    #4
  5. Krekna Mektek

    Damphyr Guest

    Krekna Mektek wrote:
    > Wow, thanx, these, especially the Little Ruby, A Lot of Objects draft
    > book, are nice links.
    >
    >
    > By the way, why are methods not named following the
    > lowercaseUppercase convention, as in Java? This way I can see more
    > directly that something is a method, and not an instance variable.
    >
    > I'd like to do it that way, but am not sure if this is against some
    > Ruby philosophy..
    >

    As with all things, it's a matter of convention.
    In Ruby the convention is to use small case with underscores i.e.
    do_the_cool_method_thing
    In the beginning I used lowUpcase (the dreaded momentum upon entry) but
    I changed very quickly and find the underscore_methods nicer to look
    upon, when not more descriptive.
    I remember a thread quite a while back, where someone had written a
    module to lowUpcase methods dynamically.
    Somehow I can't see how I would confuse instance ariables with method
    calls, but I guess it's the same thing that makes me not see the use in
    m_str and other sickly prefixes in typed languages: my way of reading code.
    Cheers,
    V.-
    --
    http://www.braveworld.net/riva

    ____________________________________________________________________
    http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
    http://www.freemail.gr - free email service for the Greek-speaking.
     
    Damphyr, Oct 5, 2005
    #5
  6. Selon Krekna Mektek <>:

    >
    > By the way, why are methods not named following the lowercaseUppercase
    > convention, as in Java?
    > This way I can see more directly that something is a method, and not
    > an instance variable.
    >


    Why? instance variables always begin with @, and methods can't, and I'd s=
    ay that
    sigil is clear enough as it is (enough that I've heard some people compla=
    in
    about its presence). For the rest, something like "obj.var =3D 5" is *alw=
    ays* a
    method call anyway (you needn't actually have a @var instance variable in=
    your
    obj, you can simply define a var=3D() method), so there's no confusion po=
    ssible.

    > I'd like to do it that way, but am not sure if this is against some
    > Ruby philosophy..
    >


    I used to be a fan of camelCase for methods myself, but I changed my mind=
    after
    reading a lot of Ruby code. CamelCase is alright for class names, since t=
    hey
    begin with a capital already, but if you begin to use it with method name=
    s it
    become quickly unreadable (in hindsight, I think it's one of the reasons =
    I've
    always found Java code confusing). And there's no possibility to confuse
    methods and instance variables anyway.
    --
    Christophe.

    http://rainbow.conlang.free.fr

    It takes a straight mind to create a twisted conlang.
     
    Christophe Grandsire, Oct 5, 2005
    #6
  7. On 10/5/05, Krekna Mektek <> wrote:
    >
    > By the way, why are methods not named following the lowercaseUppercase
    > convention, as in Java?
    > This way I can see more directly that something is a method, and not
    > an instance variable.
    >


    You may want to take a look at the Pickaxe's Book
    (http://www.rubycentral.com/book/)

    In the chapter "Classes, Objects and Variables", they mention the
    Uniform Access Principle of Bertrand Meyer. Not ot seeing the
    difference between an instance variable and a method is a Good Thing
    (anyway, you cannot access an instance variable directly in Ruby.).
    From the book:

    "By hiding the difference between instance variables and calculated
    values, you are shielding the rest of the world from the
    implementation of your class. You're free to change how things work in
    the future without impacting the millions of lines of code that use
    your class. This is a big win."

    Cheers,
    Ed
    --
    Encontr=E1 a "Tu psic=F3pata favorito" http://tuxmaniac.blogspot.com
    =09
    Thou shalt study thy libraries and strive not to reinvent them without caus=
    e,
    that thy code may be short and readable and thy days pleasant and productiv=
    e.
    -- Seventh commandment for C programmers
     
    Edgardo Hames, Oct 5, 2005
    #7
  8. Hi --

    On Wed, 5 Oct 2005, Krekna Mektek wrote:

    > Wow, thanx, these, especially the Little Ruby, A Lot of Objects draft
    > book, are nice links.
    >
    >
    > By the way, why are methods not named following the lowercaseUppercase
    > convention, as in Java?


    Because Ruby follows Ruby conventions, not Java conventions :)

    > This way I can see more directly that something is a method, and not
    > an instance variable.


    I think you mean "local variable", since instance variables can be
    spotted anyway by their leading "@". But in general you don't need to
    know whether something is a method. I know people sometimes stick
    empty parentheses on bareword method calls, also in order to see that
    it's a method, but it's never appealed to me to do so. The name
    should be descriptive enough to tell you what's going on -- and if
    you lose track of what your variables and/or method names are, you
    probably need to do some refactoring anyway :)

    > I'd like to do it that way, but am not sure if this is against some
    > Ruby philosophy..


    It's against traditional Ruby practice. I'd recommend doing things in
    as close to a traditional Ruby way as possible, and then eventually if
    you feel there are problems you can address them.


    David

    --
    David A. Black
     
    David A. Black, Oct 5, 2005
    #8
  9. Krekna Mektek wrote:
    > By the way, why are methods not named following the lowercaseUppercase
    > convention, as in Java?
    > This way I can see more directly that something is a method, and not
    > an instance variable.
    >
    > I'd like to do it that way, but am not sure if this is against some
    > Ruby philosophy..


    No problem with that. It's just, um, that you will die a slow and painful
    death if you use CamelCase. Don't ask me how it works - it's Matz
    Magic(TM) built right into your Ruby runtime.

    Seriously, I'd just stick with the convention. Makes things easier for
    other folks reading your code. When in Rome, do as the Romans do...

    Kind regards

    robert
     
    Robert Klemme, Oct 5, 2005
    #9
  10. Krekna Mektek

    Dave Howell Guest

    On Oct 5, 2005, at 8:56, Robert Klemme wrote:

    > Krekna Mektek wrote:
    >> By the way, why are methods not named following the lowercaseUppercase
    >> convention, as in Java?
    >> This way I can see more directly that something is a method, and not
    >> an instance variable.
    >>
    >> I'd like to do it that way, but am not sure if this is against some
    >> Ruby philosophy..

    >
    > No problem with that. It's just, um, that you will die a slow and
    > painful
    > death if you use CamelCase. Don't ask me how it works - it's Matz
    > Magic(TM) built right into your Ruby runtime.


    I've always found underscores hard to type and annoying to read, so
    I've never used them in any of my programming.

    All of my code looks like

    def newMartini
    attr_reader :withOlive

    def initialize(dryness)

    end

    def shakenNotStirred
    end
    end

    and so on. It's regrettable (and generally a poor design choice) that
    case is significant, so you can't capitalize the initial character of
    methods or variables, but other than that, name them as you like.

    ++ warning: rant below ++

    [Why a poor design choice? Because except for certain specific enclaves
    in computer programming (e.g. Unix, but not Mac, not Windows, not DEC
    VAX, not BASIC, not Pascal, not REXX, and not Modula-2, to draw from
    personal experience), case isn't "significant." Including, oh, the
    entire rest of the world's written literature. Nobody thinks that Dave
    and DAVE and dave are three different people, or that a Ph.D is
    different from a PH.D. Recipes can have Tbsp or tbsp, and on and on
    and on. You'd have to look long and hard, or find a Unix programmer, in
    order to find somebody who thought WordPerfect was spelled differently
    than Wordperfect, and e. e. cummings gets filed after Carter but before
    Dostoyevsky, not somewhere after the Z's. Capitalization is used for
    readability and convenience, but explicit meaning, especially
    identification, does not allow itself to change through mere
    capitalization; a message in all caps states the same things as one in
    all lower case (notwithstanding the possible *implicit* messages of
    emphasis). An italic R, a lower-case R, a cursive R, a bold R, a
    capital R: they are all the same letter, and functionally
    interchangeable. Except in a tiny minority of cases. Like Unix. And
    Ruby.]
     
    Dave Howell, Oct 6, 2005
    #10
  11. Dave Howell wrote:
    > On Oct 5, 2005, at 8:56, Robert Klemme wrote:
    >
    >> Krekna Mektek wrote:
    >>> By the way, why are methods not named following the
    >>> lowercaseUppercase convention, as in Java?
    >>> This way I can see more directly that something is a method, and not
    >>> an instance variable.
    >>>
    >>> I'd like to do it that way, but am not sure if this is against some
    >>> Ruby philosophy..

    >>
    >> No problem with that. It's just, um, that you will die a slow and
    >> painful
    >> death if you use CamelCase. Don't ask me how it works - it's Matz
    >> Magic(TM) built right into your Ruby runtime.

    >
    > I've always found underscores hard to type and annoying to read, so
    > I've never used them in any of my programming.
    >
    > All of my code looks like
    >
    > def newMartini
    > attr_reader :withOlive
    >
    > def initialize(dryness)
    >
    > end
    >
    > def shakenNotStirred
    > end
    > end
    >
    > and so on. It's regrettable (and generally a poor design choice) that
    > case is significant, so you can't capitalize the initial character of
    > methods or variables, but other than that, name them as you like.
    >
    > ++ warning: rant below ++
    >
    > [Why a poor design choice? Because except for certain specific
    > enclaves in computer programming (e.g. Unix, but not Mac, not
    > Windows, not DEC VAX, not BASIC, not Pascal, not REXX, and not
    > Modula-2, to draw from personal experience), case isn't
    > "significant." Including, oh, the entire rest of the world's written
    > literature. Nobody thinks that Dave and DAVE and dave are three
    > different people, or that a Ph.D is different from a PH.D. Recipes
    > can have Tbsp or tbsp, and on and on and on. You'd have to look long
    > and hard, or find a Unix programmer, in order to find somebody who
    > thought WordPerfect was spelled differently than Wordperfect, and e.
    > e. cummings gets filed after Carter but before Dostoyevsky, not
    > somewhere after the Z's. Capitalization is used for readability and
    > convenience, but explicit meaning, especially identification, does
    > not allow itself to change through mere capitalization; a message in
    > all caps states the same things as one in all lower case
    > (notwithstanding the possible *implicit* messages of emphasis). An
    > italic R, a lower-case R, a cursive R, a bold R, a capital R: they
    > are all the same letter, and functionally interchangeable. Except in
    > a tiny minority of cases. Like Unix. And Ruby.]


    Huh? How are printf(), Printf() and prinTf() in C the same? Did I miss
    something? Case significance of identifiers is present in a lot (if not
    most) major programming languages.

    And you can even have capital starting letters of method names in Ruby
    (although I find this utmost ugly and irritating):

    >> def Foo() "bar" end

    => nil
    >> Foo()

    => "bar"

    Regards

    robert
     
    Robert Klemme, Oct 6, 2005
    #11
  12. Hi --

    On Thu, 6 Oct 2005, Robert Klemme wrote:

    > And you can even have capital starting letters of method names in Ruby
    > (although I find this utmost ugly and irritating):
    >
    >>> def Foo() "bar" end

    > => nil
    >>> Foo()

    > => "bar"


    Also, if you want case insensitivity and don't care about traditional
    Ruby style, you can just use $Global $VaRiAbLeS all over the place.

    Which, in part, is to point out that the use of significant case is
    one of the things that makes it possible for Ruby to avoid that kind
    of line noise and still have a rich semantics.


    David

    --
    David A. Black
     
    David A. Black, Oct 6, 2005
    #12
  13. On 10/6/05, David A. Black <> wrote:
    > Also, if you want case insensitivity and don't care about traditional
    > Ruby style, you can just use $Global $VaRiAbLeS all over the place.


    Ah. My favourite. $RanSomNOtE style.

    ;)

    Sean
     
    Sean O'Halpin, Oct 6, 2005
    #13
  14. Krekna Mektek

    Jim Freeze Guest

    Well, I can think of a couple of reasons why people don't put a lot
    of meaning on case.

    1) People are sloppy
    2) Written words are just a way to represent sound, and there
    is no case in sound.

    But, a more precise language, like math, would distinguish
    between X and x. Computers just happen to be highly
    precision oriented. Not a very tolerant (ie sloppy) bunch, which,
    ultimately, I think is a good thing, when you are trying
    to describe processes.


    On 10/6/05, Dave Howell <> wrote:
    >
    > On Oct 5, 2005, at 8:56, Robert Klemme wrote:
    >
    > > Krekna Mektek wrote:
    > >> By the way, why are methods not named following the lowercaseUppercase
    > >> convention, as in Java?
    > >> This way I can see more directly that something is a method, and not
    > >> an instance variable.
    > >>
    > >> I'd like to do it that way, but am not sure if this is against some
    > >> Ruby philosophy..

    > >
    > > No problem with that. It's just, um, that you will die a slow and
    > > painful
    > > death if you use CamelCase. Don't ask me how it works - it's Matz
    > > Magic(TM) built right into your Ruby runtime.

    >
    > I've always found underscores hard to type and annoying to read, so
    > I've never used them in any of my programming.
    >
    > All of my code looks like
    >
    > def newMartini
    > attr_reader :withOlive
    >
    > def initialize(dryness)
    >
    > end
    >
    > def shakenNotStirred
    > end
    > end
    >
    > and so on. It's regrettable (and generally a poor design choice) that
    > case is significant, so you can't capitalize the initial character of
    > methods or variables, but other than that, name them as you like.
    >
    > ++ warning: rant below ++
    >
    > [Why a poor design choice? Because except for certain specific enclaves
    > in computer programming (e.g. Unix, but not Mac, not Windows, not DEC
    > VAX, not BASIC, not Pascal, not REXX, and not Modula-2, to draw from
    > personal experience), case isn't "significant." Including, oh, the
    > entire rest of the world's written literature. Nobody thinks that Dave
    > and DAVE and dave are three different people, or that a Ph.D is
    > different from a PH.D. Recipes can have Tbsp or tbsp, and on and on
    > and on. You'd have to look long and hard, or find a Unix programmer, in
    > order to find somebody who thought WordPerfect was spelled differently
    > than Wordperfect, and e. e. cummings gets filed after Carter but before
    > Dostoyevsky, not somewhere after the Z's. Capitalization is used for
    > readability and convenience, but explicit meaning, especially
    > identification, does not allow itself to change through mere
    > capitalization; a message in all caps states the same things as one in
    > all lower case (notwithstanding the possible *implicit* messages of
    > emphasis). An italic R, a lower-case R, a cursive R, a bold R, a
    > capital R: they are all the same letter, and functionally
    > interchangeable. Except in a tiny minority of cases. Like Unix. And
    > Ruby.]
    >
    >
    >



    --
    Jim Freeze
     
    Jim Freeze, Oct 6, 2005
    #14
  15. On 10/6/05, Jim Freeze <> wrote:
    > Well, I can think of a couple of reasons why people don't put a lot
    > of meaning on case.
    >
    > 1) People are sloppy
    > 2) Written words are just a way to represent sound, and there
    > is no case in sound.
    >
    > But, a more precise language, like math, would distinguish
    > between X and x. Computers just happen to be highly
    > precision oriented. Not a very tolerant (ie sloppy) bunch, which,
    > ultimately, I think is a good thing, when you are trying
    > to describe processes.


    I don't mind case-sensitive languages. It ends up discouraging
    LANGUAGES THAT LOOK LIKE THIS. That said, I think that a good "static
    analysis" step would be to look for two items of the same "class" that
    are the same when case is ignored. This would discourage things like
    dir and Dir in the same source file without actually restricting the
    behaviour.

    I do mind case-sensitive data format descriptors (e.g., how both XML
    and YAML work), preferring the case-insensitivity of HTML to XHTML,
    even though I prefer XHTML overall. There is no meaningful reason why
    "customer-number" and "Customer-Number" refer to different things.

    I *really* mind case-sensitive filesystems and think that Unix got it
    wrong. I don't see them as often anymore, but it was not uncommon a
    decade ago to see "Makefile" and "makefile" in the same directory.
    IMO, Windows and OS X HFS+ get this right: the filesystem is
    case-preserving. That is, if I save the file as Makefile, it shows as
    Makefile. But I can access it as "makefile" and the OS/filesystem will
    give me the correct file. (I also think that NTFS and HFS+ got it
    right on the filename encoding. POSIX rules are too simplistic at this
    point. UTF-8 should be enforced at the filesystem level if you're not
    going to UTF-16 like HFS+ and NTFS.)

    -austin
    --
    Austin Ziegler *
    * Alternate:
     
    Austin Ziegler, Oct 6, 2005
    #15
  16. Dave Howell wrote:
    > .... It's regrettable (and generally a poor design choice) that
    > case is significant, so you can't capitalize the initial character of
    > methods or variables, but other than that, name them as you like.
    >
    > ++ warning: rant below ++
    >
    > [Why a poor design choice? Because except for certain specific enclaves
    > in computer programming (e.g. Unix, but not Mac, not Windows, not DEC
    > VAX, not BASIC, not Pascal, not REXX, and not Modula-2, to draw from
    > personal experience), case isn't "significant." Including, oh, the
    > entire rest of the world's written literature. Nobody thinks that Dave
    > and DAVE and dave are three different people, or that a Ph.D is
    > different from a PH.D. Recipes can have Tbsp or tbsp, and on and on
    > and on. You'd have to look long and hard, or find a Unix programmer, in
    > order to find somebody who thought WordPerfect was spelled differently
    > than Wordperfect, and e. e. cummings gets filed after Carter but before
    > Dostoyevsky, not somewhere after the Z's. Capitalization is used for
    > readability and convenience, but explicit meaning, especially
    > identification, does not allow itself to change through mere
    > capitalization; a message in all caps states the same things as one in
    > all lower case (notwithstanding the possible *implicit* messages of
    > emphasis). An italic R, a lower-case R, a cursive R, a bold R, a
    > capital R: they are all the same letter, and functionally
    > interchangeable. Except in a tiny minority of cases. Like Unix. And
    > Ruby.]


    Although case is not significant in Pascal, it is in Wirth's later
    languages, Modula-2 and Oberon-2. So apparently even the creator
    of Pascal disagrees with you.
     
    William James, Oct 7, 2005
    #16
    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. Tommy
    Replies:
    2
    Views:
    362
    John C. Bollinger
    Nov 22, 2004
  2. Mike Wahler
    Replies:
    1
    Views:
    381
    Az Tech
    Aug 2, 2003
  3. Vishal Naidu

    Object orientation.....

    Vishal Naidu, Sep 1, 2005, in forum: C Programming
    Replies:
    11
    Views:
    625
    Alexei A. Frounze
    Sep 28, 2005
  4. Tom Anderson
    Replies:
    17
    Views:
    491
    Tom Anderson
    Apr 1, 2011
  5. Len Sumnler
    Replies:
    1
    Views:
    94
    Robert Klemme
    Feb 16, 2010
Loading...

Share This Page