:: -- operator or not?

[Kedar Mhaswade]

::
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.

 

[David Masover]

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?

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.

 

[Anurag Priyam]

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.

 

[Colin Bartlett]

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.

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