On 12/2/2010 11:07 AM, Doug S. wrote:
hello,
i have my first (of what may be many) really dumb questions: why is it
advantageous to be able to distinguish aVariableName from avariablename?
Are you asking why identifiers are case-sensitive?
-Jeremy
hello,
i just started with ruby. i’ve been off the front-lines of programming
for about 15 years. recently, our company was purchased by a
died-in-the-wool java shop that is just starting to adopt ruby and
rails. i’ve always had at least a working knowledge of our programming
environment, so i started investigating ruby. truth be told, i’ve never
before worked in an object oriented environment. so, when i, just
moments ago, executed a small program which demonstrates how easily even
methods in an internal (ships-with-ruby) class can be redefined, i
experienced a holy s#@! moment. well, possibly unrelated to topics
dealing with an amazing object model, i have my first (of what may be
many) really dumb questions: why is it advantageous to be able to
distinguish aVariableName from avariablename?
thanks,
doug
On Thu, Dec 2, 2010 at 6:07 PM, Doug S. [email protected] wrote:
advantageous to be able to distinguish aVariableName from avariablename?
thanks,
doug
I would not say it is advantageous. Maybe one could argue about
a_variable_name vs. AVariableName (bad example for camel case I guess)
It is a matter of taste, … [computer! erase the last sentence!]
It is a matter of style and convention, Ruby has chosen the former
style and about everybody I know sticks to it. Note that camel case is
used for constants and that helps us to distinguish those two;)
thus in Ruby it is my_variable and MyConst. in Java it would be
MyVariable and MYCONST
I believe the Ruby style is more readable but that might be because I
read almost infinitely more ruby code than Java code :P.
Cheers
Robert
On 12/02/2010 06:07 PM, Doug S. wrote:
why is it advantageous to be able to distinguish aVariableName from
avariablename?
So you basically ask why Ruby’s identifiers are case sensitive. It’s
that way in many (most?) programming languages. I suspect that what to
us humans looks like simple (identifying both variants as the same
variable) is more difficult for computers: case handling is highly
dependent on the encoding used and may actually be difficult to compute.
For a machine it is easier to just test for binary identity.
Good news is: you can actually get used to this. 
Kind regards
robert
Yes, thanks: I was asking why, when designing a language, why make
identifiers case sensitive. One list member responded that there would
be an extra overhead involved in equating, say, aVariableName with
avariablename. Overhead considerations aside, I think it would be
desirable to have identifiers be case-insensitive… ?
On Thu, Dec 2, 2010 at 2:29 PM, Doug S. [email protected] wrote:
Yes, thanks: I was asking why, when designing a language, why make
identifiers case sensitive. One list member responded that there would be
an extra overhead involved in equating, say, aVariableName with
avariablename. Overhead considerations aside, I think it would be desirable
to have identifiers be case-insensitive… ?
As an extremely visually oriented person, I think I would incur a mental
overhad as well if you could talk about the same variable/method in
different places, but have the method name look different in each of
them.
Interestingly, in JRuby, when dealing with Java libs, you can call
methods
with either snake_case, or camelCase, and both will work just fine.
On 12/2/2010 2:29 PM, Doug S. wrote:
Yes, thanks: I was asking why, when designing a language, why make identifiers
case sensitive. One list member responded that there would be an extra overhead
involved in equating, say, aVariableName with avariablename. Overhead
considerations aside, I think it would be desirable to have identifiers be
case-insensitive… ?
I can’t speak to the reasoning behind the design decision, but I see
potential problems with either methodology.
When using case-sensitive identifiers, you can make your program
confusing by purposely using capitalization differences between
identifiers in order to hold different values or carry out different
functions. In a scripting language such as Ruby, a simple typoed
identifier could cause hard to find bugs, especially if the typo was a
minor capitalization difference. It would definitely be worse if the
convention for most identifiers was camel case as that could easily hide
incorrect caps. Fortunately, I have never seen this to be a common
issue even within some outrageously bad code I’ve inherited over the
years.
OTOH, one could get pretty sloppy with identifier names, perhaps
unintentionally, if capitalization is ignored and thereby make a program
a challenge for a human to read later. Maybe that wouldn’t be a
frequent problem either though.
What would be the biggest advantage of allowing case-insensitivity in
your opinion?
-Jeremy
Overhead considerations aside, I think it would
be desirable to have identifiers be case-insensitive… ?
As Robert D. said, in Ruby, constants (Upper case) are
different beasts than variables (lower case).
An unfortunately unpasteable example:
irb(main):001:0> Hello = “I am a constant!”
=> “I am a constant!”
irb(main):002:0> hello = “I am a variable.”
=> “I am a variable.”
irb(main):003:0> Hello = “Indeed, I am a constant.”
(irb):3: warning: already initialized constant Hello
=> “Indeed, I am a constant.”
irb(main):004:0> def access_variable_example
irb(main):005:1> puts hello
irb(main):006:1> end
irb(main):007:0> access_variable_example
NameError: undefined local variable or method hello' for main:Object from (irb):5:inaccess_variable_example’
from (irb):7
from /usr/local/bin/irb:12:in `’
irb(main):008:0> def access_constant_example
irb(main):009:1> puts Hello
irb(main):010:1> end
=> nil
irb(main):011:0> access_constant_example
Indeed, I am a constant.
=> nil
It is desirable for a language to have a syntax which reflects the
semantics. Capitalization is easy to see, easy to type, and
doesn’t add any extra waffle.
Also, case sensitivity gives me more choice. I can have sockets and
Sockets and SOCKETS, and have them, individually, mean whatever I want
to.
Johnny
Robert K. wrote:
On 12/02/2010 06:07 PM, Doug S. wrote:
why is it advantageous to be able to distinguish aVariableName from
avariablename?
So you basically ask why Ruby’s identifiers are case sensitive. It’s
that way in many (most?) programming languages. I suspect that what to
us humans looks like simple (identifying both variants as the same
variable) is more difficult for computers: case handling is highly
dependent on the encoding used and may actually be difficult to compute.
It’s actually impossible. My favorite example:
def maße; end
def masse; end
MASSE # Oops. Which one do I mean?
jwm
I worked with macromedia( now adobe) lingo which was case insensitive
pre internet days. Though it was a “feature” no one used it. That
language it was more common to use hungerian notation for naming.
The token parser would have to have some extra checks and some
conversions but once turned into byte code and cached the program
should run just as fast. in c a char is still sizeof(char) and an
integer is still sizeof(int).
I would imagine the ‘design decision’ would have more to do with
creating something that is useful as opposed to making a feature which
though interesting would never be used in a real world application.
2010/12/2 Jrg W Mittag [email protected]:
def mae; end
def masse; endMASSE # Oops. Which one do I mean?
This can get even worse if you have a font with an upper case (these
exist):
MAE # Er…
That’s also a good example why Unicode is a good thing, but can be
painful when using Unicode characters to name programming constructs.
–
Phillip G.
Though the folk I have met,
(Ah, how soon!) they forget
When I’ve moved on to some other place,
There may be one or two,
When I’ve played and passed through,
Who’ll remember my song or my face.
What would be the biggest advantage of allowing case-insensitivity in your
opinion?<
Jeremy,
After feedback from this list, I don’t now see an advantage to
case-insensitivity. Prior to posting, I was thinking (perhaps grounded
from a “human reading level”) that “aVariableName” just simply should
equal “avariablename”. I also thought that having a situation where
case matters might actually increase the chance for error.
Doug
p.s. Since the topic here is identifiers, I do want the folks on this
list to know that I realize: died_in_the_wool != dyed_in_the_wool