says...
Quote:
> > So... is there another "right" way to get what I want?
> your third is right. you can use def self.m1 instead from what i
> understand, though i never do. and self will pick up the module at that
> level. that's how it works ruby allows you to define module/class
> methods by prefixing the module/class name and a period. honest
> question, how would you want it to work?
Well, any way will do, as long as I have a clear grasp of what's going on
and of the rationale behind some design choices :-) I'm exploring Ruby
and in this phase I'm really open-minded, as long as I have an
understanding of the language's workings and idioms.
It is a fact, however, that my past experiences with Perl, python and
Visual Basic, have had some (bad?) influence on my personal definition of
what a Module is.
Influenced by such languages which tend to give to 'module' the meaning
of "container of functions", I was tempted to write:
module M
private
def m2
puts "In m2"
end
def m1
m2
end
public
def m
m1
end
end
M.m
i.e., I was tempted to avoid the 'M.*' syntax, except when absolutely
needed (to specify the namespace in which m() is defined, in this case).
But... this is just too Perlish or Pythonesque, I'm afraid... I must
upgrade my mind to an OO view :-)
(warning: what follow is my personal opinion, no flame intended :-) )
I really like Ruby. Last summer I downloaded Squeak and so I
(re)discovered the beauty of Smalltalk, which I had not used for more
than 10 years (while I was graduating). I was using Python for sysadm and
text processing tasks, and comparing it with Smalltalk convinced me that
it (Python) was too much of a kludge for my personal taste. Not to talk
about the new features introduced by Python 2.2, definitely too
bizantine for me. Someone on comp.lang.pyhton mentioned Ruby, I
downloaded it and... it was what I wanted, kind-of Smalltalk without the
Smalltalk environment, usable both for scripting and quick and dirty one-
liners and for larger projects.
Probably because I'm graduated in Computer Science, I tend to consider
every language as a work of art, and before using it for something
"useful" I spend some/a lot of time to understand it and its design
choices. Under this particular point of view, I find Ruby to be quite
"beautiful", and I'll drop Python for it.
There are some things I don't like, but compared with what I don't like
in other languages they are not so important. To be honest, I'm not sure
that the freedom in syntax allowed by Ruby promotes readability. If a
line of code is:
funcname a
how do you now if you must read it as:
funcname(a) (where a is a variable)
or
funcname(self.a())
Also I don't like things that can be written in different manners,
because I think these ambiguities make code less readable. For example a
block may be delimited by 'do...end' or by '{...}': I personally prefer
'{...}', but when I read code written by others I must remember to also
look for 'do...end'...
And I still don't understand why (see my previous posts):
- aModule.constants behaves differently from aClass.constants (but there
is a very pragmatic answer here: aClass.constants-
aClass.superclass.constants will work, while aModule.constants-
aModule.superclass.constants won't)
- module Kernel defines as singleton methods (almost) all of his private
instance methods
But this are minor things, and all in all I like what I've seen so far :-
)
Thank you for your answer, and excuse me for a lengthy reply :-)
Andrea