Re: [RCR] Drop :: as a . synonym

On Fri, Apr 25, 2008 at 8:13 AM, Paul Brannan <[e-mail]> wrote:

> On Fri, Apr 25, 2008 at 08:34:20PM +0900, Nikolai Weibull wrote:
> > Why not abolish :: altogether and disallow methods that begin with an
> > uppercase letter and reserve those explicitly for constants (that
> > already must be initially capitalized)?
>
> I don't really like uppercase methods, but I wouldn't want to do without
> Integer() and Float().
>

I think that many/most cases where uppercase methods are used is when it
matches a class name and you want some Class#new type functionality.

The namespace between class/module methods and constants could be merged and
you still could get this behavior if we had one more thing: callable
objects.  The Integer() and Float() methods would correspond to calling the
Integer and Float classes.

This is an area where I think Python is a bit more elegant.  There is no
reason for separate "." and "::" operators.  "." simply does object lookup
within a scope.  That object could be a method which you can call with the
() operator.

But, I think something elegant could exist for Ruby and still use the same
syntax.  But, the first thing you need is to eliminate the overlap between
"::" and "." as David suggested.  "." could simply be treated as two
operations - "::" (lookup within scope) + "()" (call).  So, Ruby's "::"
would be equivalent to Python's ".".  Here would be a breakdown of this
proposal (replaced currying with calling):

a.b <=> a::b()
a.b x,y,z <=> a::b(x, y, z)
a.b(x,y,z) <=> a::b(x, y, z)  # parens not needed for "."
a::b <=> a.method(:b) or a.const_get(:b)  # namespaces merged for Module

So, here's a summary:
* "::" would not send, it would simply do constant/object lookup
* merge the class/module method namespace and class/module constant namespce
* "::" would be an overloadable operator
* "()" (calling) would also be an overloadable operator
* "." would be an alias for "::" plus "()".

This would clearly create compatibility issues, but you could create the
same type of API that can be done now (but the implementation would be
different - easier/consistent/natural in my opinion).  You could even use
use "::" for sending messages, but "()" would be required to invoke the call
operator.

Eric