having grokked Ruby for a while now I wonder whether there are any specific recommendations regarding file/directory naming. IF so, where's the place to look?
I've been using C++ for quite a while, and what made sense to me was to aim for one class/file and name the file after the class - e.g. MyClass => MyClass.h, MyClass.cpp.
If the class were defined inside a namespace (roughly comparable to modules in this specific instance), I'd ususally create a subdirectory reflecting that, e.g.:
--- MyNs/MyClass.h --
....
namespace MyNs {
class MyClass {};
} // namespace MyNs
....
···
---------------------
To refer to this header from other files I use e.g. "#include <MyNs/MyClass.h>". This seems pretty consistent with e.g. "require 'test/unit'".
But - back again to my real question (and now a bit more specific): why all this lower-case only in the files/directorys(that map to module names) within Ruby? As an example: compare Test::Unit::TestCase to test/unit/testcase.rb - any specific reason for this?
I like grouping functionality into one file. There is no reason like in java to have only one class per file. And I often create really small classes for simple tasks, so it would be tedious to have that many files.
On the other hand one module may stretch along various files, if those add functionality to the module. In some cases I even have multiple files per class, such that I can choose the subset of functionality I need for the class.
The only advantage of one class per file is easier browsing if you have a bad editor, but this can be overcome easily with using e.g. emacs or even a ruby ide like arachno ruby (Never tried it, but there are lots of people here on the list who seem to like it).
just my 0.02___
Brian
···
On Wed, 19 Jan 2005 17:51:02 +0900 "Johan Nilsson" <johan.nilsson@---.esrange.ssc.se> wrote:
Hi,
having grokked Ruby for a while now I wonder whether there are any specific
recommendations regarding file/directory naming. IF so, where's the place to
look?
I've been using C++ for quite a while, and what made sense to me was to aim
for one class/file and name the file after the class - e.g. MyClass =>
MyClass.h, MyClass.cpp.
If the class were defined inside a namespace (roughly comparable to modules
in this specific instance), I'd ususally create a subdirectory reflecting
that, e.g.:
--- MyNs/MyClass.h --
....
namespace MyNs {
class MyClass {};
} // namespace MyNs
....
---------------------
To refer to this header from other files I use e.g. "#include
<MyNs/MyClass.h>". This seems pretty consistent with e.g. "require
'test/unit'".
But - back again to my real question (and now a bit more specific): why all
this lower-case only in the files/directorys(that map to module names)
within Ruby? As an example: compare Test::Unit::TestCase to
test/unit/testcase.rb - any specific reason for this?
"Johan Nilsson" <johan.nilsson@---.esrange.ssc.se> schrieb im Newsbeitrag
news:1106124441.a8ad5426c16b9fc0b683d806c03ab2c5@teranews...
<snip/>
But - back again to my real question (and now a bit more specific): why
all
this lower-case only in the files/directorys(that map to module names)
within Ruby? As an example: compare Test::Unit::TestCase to
test/unit/testcase.rb - any specific reason for this?
File system portability: there are file systems out there that think
"foo.rb" is the same as "Foo.rb".
Thanks so much for pointing that out. As OpenVMS Ruby users (using the
ODS-2 filesystem,) we had to hack rubicon in the following fashion to
work around a file casing problem that breaks on our platform:
+ def classEach
+ list=
+ ObjectSpace.each_object(Class){|aClass| list << aClass}
+ list.sort{|a,b| a.to_s.upcase <=> b.to_s.upcase}.each{|entry| yield entry.to_s}
+ end
···
On Thu, 2005-01-20 at 02:46 +0900, Robert Klemme wrote:
File system portability: there are file systems out there that think
"foo.rb" is the same as "Foo.rb".
+
+ def casedClassName(name)
+ upcasedName=name.upcase
+ cased=nil
+ classEach{|className| cased=className if className.upcase==upcasedName}
+ cased
+ end
+
def run
Test::Unit.run = true
@files.each do |file|
require file
- className = File.basename(file)
- className.sub!(/\.rb$/, '')
+ # On systems which don't support mixed case filenames
+ # (principally VMS) the uncasedClassName will not match
+ # the casing of the actual class name. On such systems,
+ # casedClassName() ensures the filename is matched to a
+ # class of the same name already loaded into object space.
+ uncasedClassName = File.basename(file)
+ uncasedClassName.sub!(/\.rb$/, '')
+ className = casedClassName(uncasedClassName)
klass = eval className
runner = TestRunner.new(klass.suite, Test::Unit::UI::SILENT) #TestRunner.quiet_mode = true
Thus, it is a bad idea from a portability perspective to write code such
that the case of the filename conveys meaning.
"Brian Schröder" <ruby@brian-schroeder.de> wrote in message news:20050119151735.3b691d93@black.wg...
On Wed, 19 Jan 2005 17:51:02 +0900
[snip]
I like grouping functionality into one file. There is no reason like in java to have only one class per file. And I often create really small classes for simple tasks, so it would be tedious to have that many files.
Well, the main reason would be that user's could simple 'require' what they need to avoid loading stuff not needed. OTOH, small classes that aren't meant to be used directly by users could very well be included in the public interface classes' files. But that's my personal opinion.
If there are lots of classes that are most often used together, one could use a common file that simply groups the classes by functionality (by 'requiring' their implementation files).
On the other hand one module may stretch along various files, if those add functionality to the module.
Sure, that's pretty common for me (as I have ~1 class/file and many classes per module).
In some cases I even have multiple files per class, such that I can choose the subset of functionality I need for the class.
Interesting. So far I've only used that to extend classes that aren't "my own".
The only advantage of one class per file is easier browsing if you have a bad editor, but this can be overcome easily with using e.g. emacs or even a ruby ide like arachno ruby (Never tried it, but there are lots of people here on the list who seem to like it).
"BG - Ben Armstrong" <BArmstrong@dymaxion.ca> wrote in message news:1106157923.16968.112.camel@bgpc.dymaxion.ca...
File system portability: there are file systems out there that think
"foo.rb" is the same as "Foo.rb".
[Sorry for not writing this in a direct reponse to Robert, but my news server have already purged it]
Of course, I use one every day (case-preserving but not case-sensitive). When browsing the file system, I would still definitely prefer CamelCasedFileNamingExample.rb over camelcasedfilenamingexample.rb - IMHO itsallaboutreadability
Thanks so much for pointing that out. As OpenVMS Ruby users (using the
ODS-2 filesystem,) we had to hack rubicon in the following fashion to
work around a file casing problem that breaks on our platform:
Actually I've been doing C++ under OpenVMS for some months during the last year, and after some time trying to use third-party libraries I gave up and switched to ODS-5 (might not be an option for everyone, of course). Not to mention the problems ODS-2 caused for source control with a FreeBSD server.
I'm a bit curious about your experience with Ruby on OpenVMS. I've only downloaded, installed and tested the installation myself and it seemed to work (even though I had installation problems due to decompressing/installing from an ODS-5 disc). There seems to be quite some code manipulating paths by directly using e.g. "../.." - have you experienced any related problems?
[code snipped]
Thus, it is a bad idea from a portability perspective to write code such
that the case of the filename conveys meaning.
I definitely don't mean to imply there should be a semantic difference between 'myclass.rb' and 'MyClass.rb'. The main reason would be consistency (and that it's so much easier to read).
But, that's only my own 0.02EUR.
// Johan
···
On Thu, 2005-01-20 at 02:46 +0900, Robert Klemme wrote:
