I'm quite new to Ruby. One of the things I try to get when I learn a
new language are naming conventions. I hate to write, for instance,
Java code that looks like C++.
My question is: are Ruby's aliases intended for helping beginners
coming from other languages, or you are truly free to choose any of
the provided alternatives. For example:
is Enumerable#collect preferred over Enumerable#map
or is Array#length preferred over Array#size ?
Maybe this is a silly topic, but I haven't seen it explained anywhere.
I'm quite new to Ruby. One of the things I try to get when I learn a
new language are naming conventions. I hate to write, for instance,
Java code that looks like C++.
Heh. Not all of that is just down to naming conventions, of course.
What I sometimes do when I am switching to a new language is base a
sample program I might write in #{some_other_language} and then look
at making it more like that language. That said, I know a lot of
people who write perl code that looks like C.
My question is: are Ruby's aliases intended for helping beginners
coming from other languages, or you are truly free to choose any of
the provided alternatives. For example:
It's not about helping the beginner, it's generally about your own
style which you might choose.
is Enumerable#collect preferred over Enumerable#map
or is Array#length preferred over Array#size ?
Either. They can be used interchangeably. I happen to prefer
Enumerable#collect, although you might (if you know perl, for
instance) prefer Enumerable#map.
The choice is yours.
Where the style counts more though is in terms of casing. So for instance:
* Constants start with a capital letter.
* Method names are in snake_case.
* Class names in CamelCase.
Etc, etc. Those sorts of idioms are probably the area you should
concentrate on.
-- Thomas Adam
···
On 18/10/2007, arcadiorubiogarcia@gmail.com <arcadiorubiogarcia@gmail.com> wrote:
Where the style counts more though is in terms of casing. So for instance:
* Constants start with a capital letter.
* Method names are in snake_case.
* Class names in CamelCase.
ModuleNames are also camel cased.
Other tip:
use do and end for multi-line blocks
use {} for single line blocks
It's not a rule, just by convention.
Other other tip:
Rails is not necessarily an example of Ruby. It's an example of Ruby's tendency to become a DSL.
Many gems will show you different looking but similarly developed not-typical-Ruby-looking style.
There seems to be a tendency for DSL-like things in Ruby projects as they get developed.
I think this is a result of Ruby being very very OOPy and very flexible.
So don't be surprised when some things seem to have their own conventions contrary to "standard" (?!) Ruby
Where the style counts more though is in terms of casing. So for instance:
* Constants start with a capital letter.
* Method names are in snake_case.
* Class names in CamelCase.
ModuleNames are also camel cased.
Other tip:
use do and end for multi-line blocks
use {} for single line blocks
It's not a rule, just by convention.
Other other tip:
Rails is not necessarily an example of Ruby. It's an example of Ruby's tendency to become a DSL.
Many gems will show you different looking but similarly developed not-typical-Ruby-looking style.
There seems to be a tendency for DSL-like things in Ruby projects as they get developed.
I think this is a result of Ruby being very very OOPy and very flexible.
So don't be surprised when some things seem to have their own conventions contrary to "standard" (?!) Ruby
On the other hand... Rails does a lot of things in conformity with
traditional Ruby style, which I think is very good and perhaps very
shrewd. The main departure is a lot of method calls without
parentheses. But the Rails code adheres to two-space indenting,
standard use of this_style and ThisStyle in the appropriate places,
and other standard stylistic things that people are often fond of
pushing aside.
David
···
On Thu, 18 Oct 2007, John Joyce wrote:
--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!
True True, one must admire the dedication in Rails to consistency! It's a rare beast that you see more or less what you expect to see as you dig deeper.
I was simply referring more to the DSL type things, such as Rails' associations and validations, and of course Active Record itself. But the beauty is that from the Rails Console, everything feels like any other irb session and feels like typical Ruby.
Other tools though, like Rake, must be mystical to the Ruby newbie.
Some Ruby gems even seem like DSLs because of Ruby syntax after people come from something like C or PHP.
···
On Oct 18, 2007, at 9:27 AM, David A. Black wrote:
Hi --
On Thu, 18 Oct 2007, John Joyce wrote:
The choice is yours.
Yes. You can do as you please.
Where the style counts more though is in terms of casing. So for instance:
* Constants start with a capital letter.
* Method names are in snake_case.
* Class names in CamelCase.
ModuleNames are also camel cased.
Other tip:
use do and end for multi-line blocks
use {} for single line blocks
It's not a rule, just by convention.
Other other tip:
Rails is not necessarily an example of Ruby. It's an example of Ruby's tendency to become a DSL.
Many gems will show you different looking but similarly developed not-typical-Ruby-looking style.
There seems to be a tendency for DSL-like things in Ruby projects as they get developed.
I think this is a result of Ruby being very very OOPy and very flexible.
So don't be surprised when some things seem to have their own conventions contrary to "standard" (?!) Ruby
On the other hand... Rails does a lot of things in conformity with
traditional Ruby style, which I think is very good and perhaps very
shrewd. The main departure is a lot of method calls without
parentheses. But the Rails code adheres to two-space indenting,
standard use of this_style and ThisStyle in the appropriate places,
and other standard stylistic things that people are often fond of
pushing aside.
David
--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!
On Oct 18, 2007, at 9:27 AM, David A. Black wrote:
Hi --
On Thu, 18 Oct 2007, John Joyce wrote:
The choice is yours.
Yes. You can do as you please.
Where the style counts more though is in terms of casing. So for instance:
* Constants start with a capital letter.
* Method names are in snake_case.
* Class names in CamelCase.
ModuleNames are also camel cased.
Other tip:
use do and end for multi-line blocks
use {} for single line blocks
It's not a rule, just by convention.
Other other tip:
Rails is not necessarily an example of Ruby. It's an example of Ruby's tendency to become a DSL.
Many gems will show you different looking but similarly developed not-typical-Ruby-looking style.
There seems to be a tendency for DSL-like things in Ruby projects as they get developed.
I think this is a result of Ruby being very very OOPy and very flexible.
So don't be surprised when some things seem to have their own conventions contrary to "standard" (?!) Ruby
On the other hand... Rails does a lot of things in conformity with
traditional Ruby style, which I think is very good and perhaps very
shrewd. The main departure is a lot of method calls without
parentheses. But the Rails code adheres to two-space indenting,
standard use of this_style and ThisStyle in the appropriate places,
and other standard stylistic things that people are often fond of
pushing aside.
David
--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!
True True, one must admire the dedication in Rails to consistency! It's a rare beast that you see more or less what you expect to see as you dig deeper.
I was simply referring more to the DSL type things, such as Rails' associations and validations, and of course Active Record itself. But the beauty is that from the Rails Console, everything feels like any other irb session and feels like typical Ruby.
Other tools though, like Rake, must be mystical to the Ruby newbie.
Some Ruby gems even seem like DSLs because of Ruby syntax after people come from something like C or PHP.
--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!
And of course there's the matter of the term DSL itself, and what it
connotes (or doesn't).
Nah, not really.
A language is a language.
Film itself is not necessarily a language. Computers are not a language either.
A film is a language unto itself, but one that only the director can really claim to understand 100%.
A program can be much the same, particularly in C or Perl.
I think DSL is pretty over-used as an acronym like all other acronyms that are fashionable in computerese.
But none-the-less, domain specific language is pretty much best described as metaprogramming, where there is some attempt to create a programming language or command interface that is for the user within specific domain of activity and has functionality that is clearly for that domain only. Ideally DSLs should be easier to learn than the programming language they're created with.
