Object Orientation

[Krekna Mektek]

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.

 

[Robert Klemme]

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

 

[Dave Burt]

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

 

[Krekna Mektek]

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

 

[Damphyr]

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.

 

[Christophe Grandsire]

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.

 

[Edgardo Hames]

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

 

[David A. Black]

Hi --

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

 

[Robert Klemme]

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

 

[Dave Howell]

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.]

 

[Robert Klemme]

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):
=> "bar"

Regards

robert

 

[David A. Black]

Hi --

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

=> "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

 

[Sean O'Halpin]

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

 

[Jim Freeze]

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.

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.]

 

[Austin Ziegler]

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

 

[William James]

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