::
The Pickaxe book calls it scope resolution "operator", whereas The Ruby
Programming Language says it is not an operator because the righthand
side is not a value or expression but an identifier (which I think I
understand).
So, is :: an operator or not?
Thank you.
···
--
Posted via http://www.ruby-forum.com/.
I would say no, because as far as I can tell, it can't be overloaded. Every
other operator can be overloaded in some context. It would be kind of cool if
it could -- for example, if the following worked:
class Decorated < BasicObject
def initialize klass
@klass = klass
end
def prettiness
"I'm decorated!"
end
def method_missing name, *args, &block
@klass.public_send name, *args, &block
end
end
module Decorate
def self.::(name)
Decorated.new Object.const_get(name)
end
end
Decorate::Integer.prettiness # <== "I'm decorated!"
Of course, you can also do this kind of hack with const_missing. So I guess if
:: is an operator, . is also, seeing as method_missing does the same thing. In
any case, the above doesn't work at all -- and regardless, I don't actually
have a use case beyond what people already hack with const_missing or
Kernel#autoload.
It's a fine semantic difference, though -- I don't think it matters whether
it's an operator or not.
···
On Tuesday, January 11, 2011 05:16:24 pm Kedar Mhaswade wrote:
The Pickaxe book calls it scope resolution "operator", whereas The Ruby
Programming Language says it is not an operator because the righthand
side is not a value or expression but an identifier (which I think I
understand).
So, is :: an operator or not?
So, is :: an operator or not?
I would say no, because as far as I can tell, it can't be overloaded. Every
other operator can be overloaded in some context. It would be kind of cool if
That is not a very good way of deciding whether something is an
operator or not. There are a couple of operators (&&, ||) that can't
be overloaded, and non-operator( ref: Flanagan, and Matz), but they
can be overloaded.
It's a fine semantic difference, though -- I don't think it matters whether
it's an operator or not.
Exactly. Colloquially, you can call it whatever suits you - operator,
or separator, as long as you are aware of the semantics.
···
--
Anurag Priyam
http://about.me/yeban/
I agree. (Duck typing???)
But trying to be picky, the "definition" from The Ruby Programming
Language implies that a (binary) operator can operate on (two)
arbitrary expressions, but that :: expects the second operand to be a
constant or a method. So I'm not convinced that it's whether or not an
operator can be overloaded that is relevant, as Anurag Priyam
observed.
The following seems to bear this out, although I'm a bit puzzled why
"Q ::I" and "Q :: I" fail, but "(Q) :: I" and "q :: I" work.
class Q
p Q #=> Q
q = Q
p q #=> Q
P = 355; I = 113
p Q::I #=> 113
p Q:: I #=> 113
(p (Q ::I)) rescue (p $!) #=> #<NameError: uninitialized constant I>
(p (Q :: I)) rescue (p $!) #=> #<NameError: uninitialized constant I>
p( (Q) :: I ) #=> 113
p q :: I #=> 113
i = I
p i #=> 113
(p Q::i) rescue (p $!)
#=> #<NoMethodError: undefined method `i' for Q:Class>
end
···
On Wed, Jan 12, 2011 at 3:27 AM, David Masover <ninja@slaphack.com> wrote:
On Tuesday, January 11, 2011 05:16:24 pm Kedar Mhaswade wrote:
... The Ruby Programming Language says it is not an operator
because the righthand side is not a value or expression but an identifier.
So, is :: an operator or not?
I would say no, because as far as I can tell, it can't be overloaded. Every
other operator can be overloaded in some context.
...
It's a fine semantic difference, though -- I don't think it matters whether
it's an operator or not.