Hi,
there seems to be more than one way to execute class methods.
I've seen the form (I use the classmethod new as an example):
newObject = Classname::new
but also
newObject = Classname.new
Bothe seem to work OK.
Is there a difference? If yes, what is the difference?
Also I see :: being used in the context of modules. Can you tell me
about that as well?
Thanks!
Arie
Hi --
Hi,
there seems to be more than one way to execute class methods.
I've seen the form (I use the classmethod new as an example):
newObject = Classname::new
but also
newObject = Classname.new
Bothe seem to work OK.
Is there a difference? If yes, what is the difference?
They do both work. I've never understood why the :: exists for this
purpose, since the . is the normal way of sending messages to objects
and works perfectly well whether or not the receiver is a class. It's
on my very short list of things I'd like to see removed from Ruby.
Also I see :: being used in the context of modules. Can you tell me
about that as well?
That's for looking up names of constants in nested scopes:
module M
X = 1
end
puts M::X # 1
David
On Sun, 26 Mar 2006, NuclearFusion wrote:
--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
"Ruby for Rails" chapters now available
from Manning Early Access Program! Ruby for Rails
While we're on the topic -- I've never exactly understood what placing
the double colon at the beginning does? eg...
::FooModule::FOO_CONSTANT
?
Cheers
On Sun, 2006-03-26 at 22:33 +0900, dblack@wobblini.net wrote:
Hi --
On Sun, 26 Mar 2006, NuclearFusion wrote:
> Hi,
>
> there seems to be more than one way to execute class methods.
> I've seen the form (I use the classmethod new as an example):
> newObject = Classname::new
> but also
> newObject = Classname.new
> Bothe seem to work OK.
> Is there a difference? If yes, what is the difference?They do both work. I've never understood why the :: exists for this
purpose, since the . is the normal way of sending messages to objects
and works perfectly well whether or not the receiver is a class. It's
on my very short list of things I'd like to see removed from Ruby.> Also I see :: being used in the context of modules. Can you tell me
> about that as well?That's for looking up names of constants in nested scopes:
module M
X = 1
endputs M::X # 1
--
Jonathan Leighton
http://turnipspatch.com/ | http://jonathanleighton.com/ | http://digital-proof.org/
Hi --
> Hi,
>
> there seems to be more than one way to execute class methods.
> I've seen the form (I use the classmethod new as an example):
> newObject = Classname::new
> but also
> newObject = Classname.new
> Bothe seem to work OK.
> Is there a difference? If yes, what is the difference?They do both work. I've never understood why the :: exists for this
purpose, since the . is the normal way of sending messages to objects
and works perfectly well whether or not the receiver is a class. It's
on my very short list of things I'd like to see removed from Ruby.
Some might say this is another example of TIMTOWTDI.
However, like you, I'd like to see it changed to only use ".".
> Also I see :: being used in the context of modules. Can you tell me
> about that as well?That's for looking up names of constants in nested scopes:
module M
X = 1
endputs M::X # 1
It seems to me that dots could be used for constant references too.
Maybe someone will point out a reason why this would complicate
parsing.
On 3/26/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
On Sun, 26 Mar 2006, NuclearFusion wrote:
--
R. Mark Volkmann
Object Computing, Inc.
i think it's quite useful in the context of metaprogramming or classes or
modules as variables:
m = method_returning_an_module
m::module_method
c = method_returning_an_class
c::class_method
o = method_returning_an_object
o.object_method
i find this approach helps me understand which kind of thing my variables have
at a quick glance. it's a similar idea to naming arrays with plural words
people =
person = people.first
which some hate and some love. still, these kinds of techniques can reduce
the need for comments and preserve programmer sanity.
kind regards.
-a
On Sun, 26 Mar 2006 dblack@wobblini.net wrote:
Bothe seem to work OK.
Is there a difference? If yes, what is the difference?They do both work. I've never understood why the :: exists for this
purpose, since the . is the normal way of sending messages to objects
and works perfectly well whether or not the receiver is a class. It's
on my very short list of things I'd like to see removed from Ruby.
--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama
Hi --
While we're on the topic -- I've never exactly understood what placing
the double colon at the beginning does? eg...::FooModule::FOO_CONSTANT
?
It forces a top-level lookup. For example:
class M
class String
end
def initialize
@ms = String.new # this will be M::String
@str = ::String.new("abc") # this will be top-level string
end
end
It's like a / at the beginning of a file path.
David
On Sun, 26 Mar 2006, Jonathan Leighton wrote:
--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
"Ruby for Rails" chapters now available
from Manning Early Access Program! Ruby for Rails
Hi --
Hi --
Hi,
there seems to be more than one way to execute class methods.
I've seen the form (I use the classmethod new as an example):
newObject = Classname::new
but also
newObject = Classname.new
Bothe seem to work OK.
Is there a difference? If yes, what is the difference?They do both work. I've never understood why the :: exists for this
purpose, since the . is the normal way of sending messages to objects
and works perfectly well whether or not the receiver is a class. It's
on my very short list of things I'd like to see removed from Ruby.Some might say this is another example of TIMTOWTDI.
They'd be right, but that's the *Perl* slogan, not the Ruby slogan 
(even though it's factually true of a number of things in Ruby)
However, like you, I'd like to see it changed to only use ".".
Also I see :: being used in the context of modules. Can you tell me
about that as well?That's for looking up names of constants in nested scopes:
module M
X = 1
endputs M::X # 1
It seems to me that dots could be used for constant references too.
Maybe someone will point out a reason why this would complicate
parsing.
I'd rather just have a message-sending operator (.) and a
constant-lookup operator (::). These are completely different
operations, and I don't think overlap in either direction is useful.
David
On Mon, 27 Mar 2006, Mark Volkmann wrote:
On 3/26/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
On Sun, 26 Mar 2006, NuclearFusion wrote:
--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
"Ruby for Rails" chapters now available
from Manning Early Access Program! Ruby for Rails
Hi --
Bothe seem to work OK.
Is there a difference? If yes, what is the difference?They do both work. I've never understood why the :: exists for this
purpose, since the . is the normal way of sending messages to objects
and works perfectly well whether or not the receiver is a class. It's
on my very short list of things I'd like to see removed from Ruby.i think it's quite useful in the context of metaprogramming or classes or
modules as variables:m = method_returning_an_module
m::module_methodc = method_returning_an_class
c::class_methodo = method_returning_an_object
o.object_methodi find this approach helps me understand which kind of thing my variables have
at a quick glance. it's a similar idea to naming arrays with plural wordspeople =
person = people.firstwhich some hate and some love.
Does anyone hate calling a variable person?
still, these kinds of techniques can reduce the need for comments
and preserve programmer sanity.
I honestly don't see any connection between the two techniques (:: and
suggestive variable names). c::meth doesn't communicate anything to
me about c. Even if it did, I'm not sold on the idea that it's
necessary to have a different message-sending operator for a
particular class of objects. It doesn't scale: you can come up with
lots of variable names (my_class, etc.), but you can't keep adding
operators to make distinctions among receivers. Nor is it necessarily
vital in very many cases to make such distinctions.
And when it's a matter of String.new vs. String::new, you already know
it's a class anyway
David
On Mon, 27 Mar 2006, ara.t.howard@noaa.gov wrote:
On Sun, 26 Mar 2006 dblack@wobblini.net wrote:
--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
"Ruby for Rails" chapters now available
from Manning Early Access Program! Ruby for Rails
Ah okay, thanks very much.
On Sun, 2006-03-26 at 23:44 +0900, dblack@wobblini.net wrote:
Hi --
On Sun, 26 Mar 2006, Jonathan Leighton wrote:
> While we're on the topic -- I've never exactly understood what placing
> the double colon at the beginning does? eg...
>
> ::FooModule::FOO_CONSTANT
>
> ?It forces a top-level lookup. For example:
class M
class String
enddef initialize
@ms = String.new # this will be M::String
@str = ::String.new("abc") # this will be top-level string
end
endIt's like a / at the beginning of a file path.
--
Jonathan Leighton
http://turnipspatch.com/ | http://jonathanleighton.com/ | http://digital-proof.org/
Thanx for your clear answers David!
Arie
I honestly don't see any connection between the two techniques (:: and
suggestive variable names). c::meth doesn't communicate anything to me
about c.
it does though - you know c __must__ be a module (classes being modules).
Even if it did, I'm not sold on the idea that it's necessary to have a
different message-sending operator for a particular class of objects. It
doesn't scale: you can come up with lots of variable names (my_class, etc.),
but you can't keep adding operators to make distinctions among receivers.
Nor is it necessarily vital in very many cases to make such distinctions.
i can see that point of view. still, i like this:
harp:~ > cat a.rb
module A
module B
module C
class D; end
E = 42
def self::foo() 42 end
end
end
end
namespace = A:
:C
p namespace:
p namespace::E
p namespace::foo
harp:~ > ruby a.rb
42
and i think it's why '::' can call methods - though this is a w.a.g.
And when it's a matter of String.new vs. String::new, you already know it's
a class anyway
only sometimes though:
module M
class C
end
end
def C(*a, &b) :
:C::new(*a, &b) end
C.new
this is contrived, but String is a perfect example of this: both String() and
String exist and certainly many libs export 'const methods'.
all you really when a variable starts with [A-Z] is that it's a const. this
happends quite a bit in my code because i always wrap up code into modules so i
end up with things like this:
module M
module Logging
end
module Util
end
class A
include Util
include Logging
end
class B
include Util
include Logging
end
class C
include Util
include Logging
end
def self::new *a, &b
C::new *a, &b
end
end
where 'C' is sort of the 'default' or 'main' class in this set - so i provide
a convenience method for the common ctor case. of course you can use '.new'
here... i'm just pointing out that a lefthand side const may not be a class.
regards.
-a
On Mon, 27 Mar 2006 dblack@wobblini.net wrote:
A::C:
--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama
Hi --
I honestly don't see any connection between the two techniques (:: and
suggestive variable names). c::meth doesn't communicate anything to me
about c.it does though - you know c __must__ be a module (classes being modules).
Why?
c = "abc"
c::split(//) # ["a", "b", "c"]
Even if it did, I'm not sold on the idea that it's necessary to have a
different message-sending operator for a particular class of objects. It
doesn't scale: you can come up with lots of variable names (my_class, etc.),
but you can't keep adding operators to make distinctions among receivers.
Nor is it necessarily vital in very many cases to make such distinctions.i can see that point of view. still, i like this:
harp:~ > cat a.rb
module A
module B
module C
class D; end
E = 42
def self::foo() 42 end
end
end
endnamespace = A:
p namespace:
p namespace::E
p namespace::fooharp:~ > ruby a.rb
A:
42and i think it's why '::' can call methods - though this is a w.a.g.
To each his own. My brain has to parse "namespace::foo" twice: the
first time it says, "Didn't he mean namespace::Foo?" and the second
time it says, "Oh right, Ruby's superfluous message-sending operator"
And when it's a matter of String.new vs. String::new, you already know it's
a class anywayonly sometimes though:
module M
class C
end
enddef C(*a, &b) :
C.new
this is contrived, but String is a perfect example of this: both String() and
String exist and certainly many libs export 'const methods'.all you really when a variable starts with [A-Z] is that it's a const. this
happends quite a bit in my code because i always wrap up code into modules so i
end up with things like this:module M
module Logging
end
module Util
end
class A
include Util
include Logging
end
class B
include Util
include Logging
end
class C
include Util
include Logging
end
def self::new *a, &b
C::new *a, &b
end
endwhere 'C' is sort of the 'default' or 'main' class in this set - so i provide
a convenience method for the common ctor case. of course you can use '.new'
here... i'm just pointing out that a lefthand side const may not be a class.
Absolutely -- indeed, it can be anything. (My String example was
meant to evoke the specific case of a well-know class.) That's why I
don't find it informative. I don't know; I guess I just see the
notion of "sending a message to an object" fully covered, on the
operator side (as opposed to the "send" side), by the dot, and no
clear rationale for Ruby having two such operators.
David
On Mon, 27 Mar 2006, ara.t.howard@noaa.gov wrote:
On Mon, 27 Mar 2006 dblack@wobblini.net wrote:
--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)
"Ruby for Rails" chapters now available
from Manning Early Access Program! Ruby for Rails
it does though - you know c __must__ be a module (classes being modules).
Why?
c = "abc"
c::split(//) # ["a", "b", "c"]
wow. i never noticed that!
harp:~ > ruby a.rb
A:
42and i think it's why '::' can call methods - though this is a w.a.g.
To each his own. My brain has to parse "namespace::foo" twice: the first
time it says, "Didn't he mean namespace::Foo?" and the second time it says,
"Oh right, Ruby's superfluous message-sending operator"
funny - i guess my old c-- habits are showing through!
Absolutely -- indeed, it can be anything. (My String example was meant to
evoke the specific case of a well-know class.) That's why I don't find it
informative. I don't know; I guess I just see the notion of "sending a
message to an object" fully covered, on the operator side (as opposed to the
"send" side), by the dot, and no clear rationale for Ruby having two such
operators.
yeah - i really do see that. i bounce back and forth sometimes. i guess
there are just cases where, to me, the '::' seems to look better - but it is
certainly non-essentially and non-orthogonal. fortunately we are not
programming python or all such fluff would be removed! 
regards.
-a
On Mon, 27 Mar 2006 dblack@wobblini.net wrote:
--
share your knowledge. it's a way to achieve immortality.
- h.h. the 14th dali lama