Re: Non-declared variables

From: Martin C. [mailto:[email protected]]

Every language feature that reduces how much typing I have
to do is a tangible benefit to me. It eases stress on my
body machine, and speeds the delivery of my code.

That seems a ridiculous thing to say to me. Time taken to type out
code is not the limiting factor in your productivity.

You’re right, it’s too much of a blanket statement. I would not want to
program in APL[1], for example, despite it’s terseness.

On the other hand, I wouldn’t want added to Ruby requirements to:

  • Declare all my variables before using them.
  • Write out Block.new( arg1, arg2 ){ body } for all blocks.
  • Use ‘definition’ in place of ‘def’
  • Put parentheses around all method calls
  • Use .send( “foo=”, 12 ) to invoke a setter method
  • Include types for every variable, argument, and method return
    (either as static types or ‘suggestions’)

etc.

The original post in this thread suggests that omitting declarations of
variables leads to debugging problems for no real gain. My intended
point was that (for me) a lot of Ruby’s elegance comes from its
simplicity of expression. Ruby doesn’t do anything that I can’t do in
Lua or JavaScript, except make my life as a programmer way easier.

[1] http://en.wikipedia.org/wiki/APL_programming_language

“Gavin K.” [email protected] writes:

The original post in this thread suggests that omitting declarations of
variables leads to debugging problems for no real gain. My intended
point was that (for me) a lot of Ruby’s elegance comes from its
simplicity of expression. Ruby doesn’t do anything that I can’t do in
Lua or JavaScript, except make my life as a programmer way easier.

I think what the OP was getting at is that assignment syntax is
identical to declaration syntax, and there’s no clear distinction
between the two. Therefore, when you want an assignment to be an
assignment of an already declared variable, you have nothing checking
you for typos.

This has nothing to do, by the way, with variable typing. As an
example, perl with the “strict” flag on behaves this way, requiring
variables to be declared before use and most perl programmers don’t
find the extra checking cumbersome (in fact, if you go to perlmonks,
the first thing they’ll ask you to do is to turn on “use strict”).
Although variables can be declared in outher ways (it is, after all,
perl) most perl programmers just put "my " in front of their first
usage of a variable, and that’s that. You can declare and assign in
one statement, or do them in two.

In ruby, I imagine that we’d evolve some syntax like this:

class Foo
def initialize(name, thing)
n @name = name
n @thing = thing
n @count = 0
end

def inc
# This line is an error at class definition parse time, because
# I typoed a variable name
@coutn += 1
end

def compute
# these four will be initialized to nil
n a,b,c,d
# I can now use a, b, c, and d as local variables without further
# declaration.
end
end

Note that separating declaration from assignment also makes it dirt
simple to decide the proper scope of a variable, instead of having to
have the switch between ruby 1.9 and ruby 2.0 of various scoping
details.

I’d welcome such a syntax to ruby - requiring, of course, a per-file
strictness switch; no point in killing backwards compatibility - and I
think that the extra typing would provide sufficient benefit to be
worth it. Note that block parameters are already declared in the ||
list at the start of the block, so nothing changes in:
myArray.each {|a,b| alert(a,b)}
although I may want to think carefully about what that block means in
the presence of a declared variable called ‘b’ in the surrounding
scope. I generally wouldn’t want the variable capture ruby does
presently, but some might.

Its probably best to have a strict option like in perl and VB.net. If
I am understanding what Daniel is saying properly and ruby works in
such a way that what should be a typo that generates an error is
accepted by ruby as a legit variable in spite of the fact that the
programmer really meant to say count it creates a set of situations
that are very error prone and that is not a good thing.

Kevin O. wrote:

Its probably best to have a strict option like in perl and VB.net. If
I am understanding what Daniel is saying properly and ruby works in
such a way that what should be a typo that generates an error is
accepted by ruby as a legit variable in spite of the fact that the
programmer really meant to say count it creates a set of situations
that are very error prone and that is not a good thing.

I very much agree, being a longtime Perl programmer (10+ years). When
“use strict” was first introduced, a very similar discussion ensued on
the Perl lists about how it was going to be cumbersome/etc. As Kevin
says, years later the first thing everyone says in Perl-land is to “use
strict”, so much that many discussions have considered turning it on by
default.

My one comment would be to use a common idiom in other languages, like
“var”, rather than “n”.

BTW, howdy all (first post).

Cheers,
Nate

On Wed, 18 Oct 2006, Nate W. wrote:

lists about how it was going to be cumbersome/etc. As Kevin says, years later
the first thing everyone says in Perl-land is to “use strict”, so much that
many discussions have considered turning it on by default.

My one comment would be to use a common idiom in other languages, like “var”,
rather than “n”.

BTW, howdy all (first post).

it’s a nice idea, but not as a default, consider Object#method_missing,
Module#const_missing, etc. they rely on being fired when something is
not
defined…

-a

On Wed, 18 Oct 2006, Kevin O. wrote:

Its probably best to have a strict option like in perl and VB.net. If
I am understanding what Daniel is saying properly and ruby works in
such a way that what should be a typo that generates an error is
accepted by ruby as a legit variable in spite of the fact that the
programmer really meant to say count it creates a set of situations
that are very error prone and that is not a good thing.

harp:~ > ruby -W -e’ @var=42; p @typo
-e:1: warning: instance variable @typo not initialized
nil

a: it’s hard to follow.

q: why is top posting bad?

-a

On 10/17/06, [email protected] [email protected] wrote:

it’s a nice idea, but not as a default, consider Object#method_missing,
Module#const_missing, etc. they rely on being fired when something is not
defined…

Not only that. Consider that the ‘my’ operator in perl is more than
just a convenient way to get the interpreter to check your spelling
with the strict pragma. It’s actually there as a scoping construct:
if you don’t declare a variable with ‘my’, what you get is a package
(global) variable rather than a lexical.

Louis J Scoras wrote:

if you don’t declare a variable with ‘my’, what you get is a package
(global) variable rather than a lexical.

I don’t think it needs to be a default but it could be advisable to
encourage its use especially among people new to Ruby and/or programming
in general. I have not come to the point where the things I write in
ruby are particularly long but I can easily see that as my programs get
larger and larger I am more likely to run into this quirk.
Autocompletion is great and all but it’s a bit of a crutch in this case;
after all what happens if I have to end up coding in notepad or
something like that? (I think I would just kill myself if I had to code
anything in notepad…but it could happen.)

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs