[…]
@parent = nil
@prevsibling = nil
@nextsibling = nil
@firstchild = nil
@lastchild = nil
Variables are created when they’re first referenced, and are `nil’ by
default, so these lines make no difference.
mostly right, but here is one exception:
#!/opt/ruby/1.8/bin/ruby -w
if @foo==:bar
puts “hello”
end
gives a warning.
Patrick
(and there is another exception that vnpenguin@gmail recently came
across)
Taking things a bit further, is there any reason why one shouldn’t
use both capitalization and underscores in class names, as:
A_Class_Name
Would it confuse either the interpreter or a possible reader?
-r
Hi –
On Fri, 9 Dec 2005, Rich M. wrote:
Taking things a bit further, is there any reason why one shouldn’t
use both capitalization and underscores in class names, as:A_Class_Name
Would it confuse either the interpreter or a possible reader?
Underscores are allowed in constant names, but they’re usually used
when both parts are all uppercase, which is usually not true of class
names. So A_Class_Name would be parsed, and probably understood by
humans, but it sort of a pastiche of different styles or conventions.
David
–
David A. Black
[email protected]
“Ruby for Rails”, forthcoming from Manning Publications, April 2006!
Tim H. [email protected] writes:
real Ruby code has all methods named in lowerCamelCase. -_-
Ah. Now it all makes sense. Thanks!
Yeah, the term “camelCase” doesn’t have anything to do with Perl, and I
don’t
even think that the style is particularly prevalent in Perl, but I
haven’t
scanned CPAN to see. It is, on the other hand, the official preferred
style in
Java, used throughout the standard Java class library and by most Java
development shops. It’s also closely associated with Hungarian
Notation, which
is prevalent in Microsoft code (that is, code written by them and code
written
for their platforms) pretty much irrespective of language (VC++, C#, VB,
etc.).
Ezra Z. [email protected] writes:
The human eye picks out words by shape. We use spaces between
words to separate those shapes into easily digested chunks.
OneLongWord is not a shape we are use to, so we have to stop and
think. Unfortunately, spaces aren’t allowed in programming
variables.
I’d say, rather,
“Fortunately, spaces aren’t allowed in programming variables.”
Spaces are allowed in identifiers in AppleScript, while simultaneously
being
used as separator, and the result can be quite confusing. I pretty much
don’t
read AppleScript without using an IDE that underlines recognized
identifiers:
an underlined space means the two underlined words on either side of it
are all
one long identifier, while a non-underlined space means they’re two
separate
keywords.
On Fri, Dec 09, 2005 at 04:48:07AM +0900, Rich M. wrote:
Taking things a bit further, is there any reason why one shouldn’t
use both capitalization and underscores in class names, as:A_Class_Name
Would it confuse either the interpreter or a possible reader?
Probably not, but it would confuse the heck out of my fingers.
–
Chad P. [ CCD CopyWrite | http://ccd.apotheon.org ]
unix virus: If you’re using a unixlike OS, please forward
this to 20 others and erase your system partition.
Rich [email protected] wrote:
I’d be interested to know why it is a language convention, and more
important why it is a lanaguage convention that from this thread it
seems rubyists vigorously insist upon? For those of us who were
“raised” with a language like Java (or as some on this list may say,
brain damaged ;-), lowerCamelCase seems more pleasing to the eye than
identifiers_with_underscores.
As Ezra stated elsewhere (and as frequently stated in the Perl
community), it’s much more difficult for non-native English
speakers to read squishedCaps, and for that matter, it’s not
always terribly simple for native English speakers to do so.
I can personally attest to this phenomenon, especially from
reading Japanese. After a semester of the language, and some
additional self-study, I can now (usually) tell the difference
between katakana, hiragana, and kanji in a sentence. And since
a common Japanese sentence won’t contain any spaces at all, and
the fact that many Japanese words contain both kanji and
hiragana together, I gain more and more respect for any
non-English speakers reading my code.
Which is more pleasing is apparently a matter of personal
preference. Which we should use isn’t necessarily such
a selfish decision.
Cheers,
Tim H.
On 12/8/05, Tim H. [email protected] wrote:
a common Japanese sentence won’t contain any spaces at all, and
the fact that many Japanese words contain both kanji and
hiragana together, I gain more and more respect for any
non-English speakers reading my code.
I didn’t think about that. I suppose Ruby’s multi-lingual origins and
usage would rightly demand this sort of thing.
Which is more pleasing is apparently a matter of personal
preference. Which we should use isn’t necessarily such
a selfish decision.
I’d have never considered an aesthetic judgement to be selfish, though
I suppose rendering my code unreadable by many over one could be
Elf M. Sternberg [email protected] wrote:
So the wording is “Variables are created when they’re first
assigned”, as in Python or Perl?
Perl takes this a bit farther, and calls it autovivification.
(It’s a very useful feature when needed, but can be confusing.
Aside from the standard “assignmeng” such as:
$string = "a string";
@array = qw/ a list of stuff /;
Which both declare and define a scalar varable, and an array,
respectively.
Perl will also do:
$other_array[3] = "arbitrary stuff";
$some_hash{name} = "random j. programmer";
The first statement will at once: (1) create an array
@other_array and (2) set it’s fourth element to a string. The
second statement will at once (1) create a hash %some_hash, and
(2) assign a string value to it’s “name” key.
This feature is used less since the ‘use strict;’ pragma has
become such an habitual feature in scripts.
Cheers,
Tim H.
At 11:42 PM +0900 12/8/05, James Edward G. II wrote:
The human eye picks out words by shape. We use spaces between words
to separate those shapes into easily digested chunks. OneLongWord is
not a shape we are use to, so we have to stop and think.
Unfortunately, spaces aren’t allowed in programming variables. The _
character is allowed though and the next best thing, so we go with that.
What he said. Also, we need to optimize for the “read” case:
Code is written once, but may be read many times.
The reading may be done under great stress and time pressure.
If information is discarded in the writing process, it may
not be possible to retrieve it in the reading process.
-r
James Edward G. II wrote:
We feel exactly the opposite. That’s your why.
The human eye picks out words by shape. We use spaces between words to
separate those shapes into easily digested chunks. OneLongWord is not
a shape we are use to, so we have to stop and think. Unfortunately,
spaces aren’t allowed in programming variables. The _ character is
allowed though and the next best thing, so we go with that.This is all my opinion, of course.
I share this, and I think ruby capable editors could be told to gray out
underscores within variable and method names. (so that they are visible
but can be easily ignored while reading).
just my 0.2 eurocent.
Rich M. [email protected] writes:
Taking things a bit further, is there any reason why one shouldn’t
use both capitalization and underscores in class names, as:A_Class_Name
Would it confuse either the interpreter or a possible reader?
It would remind people too much of Ada.
i guess this thread comes to something like:
when in Ruby do as the Rubyists do, or don’t if it bugs you.
I’d be interested to know why it is a language convention, and more
important why it is a lanaguage convention that from this thread it
seems rubyists vigorously insist upon? For those of us who were
“raised” with a language like Java (or as some on this list may say,
brain damaged ;-), lowerCamelCase seems more pleasing to the eye than
identifiers_with_underscores.
raise BrainDamagedException(Java)
We like UpperCamelCase, but don’t like the lowerCamelCaseCompromise.
Part of it is just getting used to, but …
I share this, and I think ruby capable editors could be told to gray out
underscores within variable and method names. (so that they are visible
but can be easily ignored while reading).
Gray out? No way. Have you ever printed var_with_underscore on a printer
that places your underscore lower than you want? Absolutely unreadable.
I think that the underscore is not a space and not a dot, but
clearly,
visibly connects the words. Especially in Ruby where “method param” is
perfectly valid, but totally different from the equally valid
“method_param”.
When I tried SciTe (I think it was scite) recently, some folding striked
the
this-is-folded-line right through the underscores. That was an immediate
turn-off for me.
Bye,
Kero.
PS: old habits die hard. Accidentally, I came from Java to Ruby, too.
Yes, I
frowned upon the underscores when I started (at the time, we had the
printer
mentioned above at work; a2ps helps). Right now, I think it is ‘just a
convention’ and should be followed. For completeness, when I started
with
Java, I frowned upon lowerCamelCase. I still do.
On Dec 9, 2005, at 7:39 AM, Steve L. wrote:
For awhile I was trying to get Node.pm to use two iterators with
blocks
instead of the traditional callback routines (actually in addition
– I want
to keep all features in Node.pm and Node.py), but there’s not a
yield_a and
yield_b command, so I couldn’t do it with both the entry and exit
callbacks,
and having them each fire at the right time is vital.
Just capture the blocks into Proc objects and use Proc#call to invoke
the block:
def on_entry(&block)
@on_entry = block
end
def on_exit(&block)
@on_exit = block
end
def main
@on_entry && @on_entry.call( # entry args go here)
# do stuff
@on_exit && @on_exit.call( # exit args go here)
end
Maybe this will give you some ideas.
Gary W.
On Friday 09 December 2005 03:17 am, Francois P. wrote:
i guess this thread comes to something like:
when in Ruby do as the Rubyists do, or don’t if it bugs you.
Yes, and I’d like to thank everyone who gave me their ideas. Most of the
ideas
I’ll use instantly. A few I might not. I see parallel assignment as less
readable than individual assignment statements.
I really love all the shortcuts Ruby gives you to get things done. And I
love
that the shortcuts don’t harm encapsulation or other positive code
qualities.
For awhile I was trying to get Node.pm to use two iterators with blocks
instead of the traditional callback routines (actually in addition – I
want
to keep all features in Node.pm and Node.py), but there’s not a yield_a
and
yield_b command, so I couldn’t do it with both the entry and exit
callbacks,
and having them each fire at the right time is vital.
Once again, thanks everyone – it was like Ruby Boot Camp.
SteveT
Steve L.
On 12/8/05, Rich [email protected] wrote:
I’d be interested to know why it is a language convention, and more
important why it is a lanaguage convention that from this thread it
seems rubyists vigorously insist upon? For those of us who were
“raised” with a language like Java (or as some on this list may say,
brain damaged ;-), lowerCamelCase seems more pleasing to the eye than
identifiers_with_underscores.
I’ll say why I tend to insist on it: Because more or less any
consistent convention makes it easier to work with code than having
code that is mixed between two or more different conventions. Ruby
has a convention that is followed a lot, including being in all the
standard libraries.
This means that your code can either be single convention - following
that convention - or it can be multi-convention, by adding your own
style in addition to the standard one. I consider single convention
to more or less always be better.
Eivind.
On 12/8/05, Rich [email protected] wrote:
I’d be interested to know why it is a language convention, and more
important why it is a lanaguage convention that from this thread it
seems rubyists vigorously insist upon? For those of us who were
“raised” with a language like Java (or as some on this list may say,
brain damaged ;-), lowerCamelCase seems more pleasing to the eye than
identifiers_with_underscores.
I was “raised” on C and then went to Java and am now learning Ruby, so
underscores are I what I started with. In trying to conform to the
Ruby conventions, it is a welcome thing to go back to underscores
instead of camelCase, but that’s just my own preference.
later…
jim
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs