Proposal - enforce lower_case for variables and methods

In matters of religion, isn’t it best to let people choose their own?

It seems to me that when religion is forced on or denied from people
from some authority, it often causes more problems than it solves.
It’s better to let people be converted of their own free will, or not, as
it were.

Of course, I don’t want to be inflamatory, so religion above should be
taken to refer only to method/variable naming, brace/indentation schemes,
and text editor preferences. :slight_smile:

  • Dan
···

On Wednesday 24 March 2004 8:59 am, Simon Strandgaard wrote:

Its about breaking as much as possible in the transition to Rite,
somebody has to raise the nasty questions, and this question is in
paticular about religion.

this is a constructor. something which is named as the class it belongs to.
so it even has to be uppercase.

regards,
~ibotty

···

On Wed, Mar 24, 2004 at 09:19:28PM +0900, Anders Borch wrote:

there’s also a .NET bridge, the .net libraries capitalize their method
names… should we allow foo.SomeDotNetMethod(123)? this is not an
argument either way, just a question.

Kernel.Integer(“1”)
=> 1

Is Ruby-Lint, a static analysis tool ?

Ruby indeed needs that.

···

On Wed, 24 Mar 2004 09:59:28 +0100, Anders Borch wrote:

Robert Klemme wrote:

“Charles Comstock” cc1@cec.wustl.edu schrieb im Newsbeitrag
news:c3r7ov$3g7$1@newsreader.wustl.edu…

I would probably prefer most library code to have similar conventions,
but I generally chafe against restrictions which seem reasonably
arbitrary like this one. It’s one of my chief reasons I never learned
python that they had arbitrary rules like this.

How about a command line option for warnings? Or someone provides a
Ruby-Lint that takes care of that. I’d vote against hard enforcement
though. It’s not rubyish. :slight_smile:

ruby-lint is a much better idea. I’d put my vote on a ruby-lint in
stead. We should have had a ruby-lint a long time ago, maybe I’ll have a
look at writing one :slight_smile:


Simon Strandgaard

[snip]

There are various cases where I want to map some string from the outside
world to a method invocation. For example, when stream processing XML.
Any restrictions on naming makes this harder, particularly if I don’t
control the naming conventions for the source XML.

sounds cludgy.

It’s actually quite elegant, and takes advantage of much of Ruby’s
dynamic nature. Try it some time and see if you change your mind.

Do you have a url ?

I am very curious to know where mixed case can be useful.
I have a short section about Ruby’s naming conventions, but having
big trouble explaining why Uppercase letters is allowed in varnames and
methods. But I should probably write something about its because Ruby aims
to be nice to Java people :wink:

this is a very early sneak preview… (in danish)
http://neoneye.dk/rubybook/

···

On Thu, 25 Mar 2004 01:58:29 +0900, James Britt wrote:


Simon Strandgaard

ibotty wrote:

allow foo.SomeDotNetMethod(123)?
Kernel.Integer(“1”)
=> 1
this is a constructor. something which is named as the class it belongs to.
so it even has to be uppercase.

Wrong.

This is a method:

irb(main):001:0> Kernel.method(:Integer)
=> #<Method: Kernel.Integer>

This is a constructor:

irb(main):002:0> String.method(:new)
=> #<Method: Class#new>

The difference might be hard to tell, but constructors certainly don’t
have to start with capitals and they’re usually methods on the classes
of whom they create instances.

regards,
~ibotty

More regards,
Florian Gross

Simon Strandgaard wrote:

I am very curious to know where mixed case can be useful.
I have a short section about Ruby’s naming conventions, but having
big trouble explaining why Uppercase letters is allowed in varnames and
methods.

Interesting perspective. I would think that such explanations would
only be needed when Ruby allows something that seems to contradict some
fundamental language construct. Otherwise, users should assume they are
free to do as they like, rather than think they need permission to do
something.

For example, I at first assumed that a class name could be anything I
wanted. I found out that was false, but that there’s a particular reason
for it; it’s part of the Ruby ground rules, and it allows the
interpreter to make certain assumptions about your code, such that other
things are either easier to do (or simply possible).

In general, I expect that if a language prevents me from doing something
it’s because the restriction buys me greater freedom someplace else.

That may be the case for adding more restrictions to method name
formats, but I’ve yet to see a compelling argument.

(I’ve read some discussion threads [not here] about proposed changes to
Sun’s Java™, and they often concern removing restrictions; the
typical response to these requests is that they shouldn’t be allowed,
because user’s can’t be trusted with too much freedom. Pretty funny.)

But I should probably write something about its because Ruby aims
to be nice to Java people :wink:

Close; it’s because Ruby aims to be nice to all people.

James

Wrong.

yep, you are right…
(stick with one language when you can, or simply dont say anything about one
language then, i learned)

thx,
~ibotty