Re: Why limit class def to a constant or colon node?

To get rid of ambiguity with extension, why not just say that "<" 
signifying extension has higher priority than "<" as an operator? That 
way, you could unambiguously write

class class_maker(); ...; end

or even

class class_maker() < String; ...; end

And if for some crazy reason a < operator returned a class, you could write

class (something < something_else); ...; end

That seems to me to be the most reasonable way to go.

- Nathan

Charles Oliver Nutter wrote:
> Rick DeNatale wrote:
>> It seems to me that java package naming maps more natuarally to nested
>> Ruby modules
>>
>> why not
>>
>> module Java
>> end
>>
>> module Java::Lang
>> end
>>
>> class Java::Lang::System
>> end
>
> Actually something very similar to this is planned for post 1.0, but 
> for now to make the syntax as friendly as possible it uses method 
> tricks...
>
> java.lang.System
>
> ...calls "java", returning the "java" package object, then calls 
> "lang" on that package, returning the "java.lang" package object, then 
> calls System on that package, returning the "java.lang.System" proxy 
> class. But in the future, I think it would better map to exactly what 
> you've described, in addition to having the Ruby class hierarchy 
> representing Java types map directly to the Java type hierarchy, with 
> modules playing the role of interfaces.
>
> But I still think being able to do
>
> class some_method(); da da da; end
>
> ...makes sense.
>
> - Charlie
>
>