Alternate notation for eigenclass

Ruby
1

Rather then using a specific method for accessing the
singleton/eigennclass, could we just use an alternate to dot-notation.
I.e. Instead of ‘x.eigenclass.foo’ either ‘x:foo’ or ‘x!foo’, or
somthing like that.

I haven’t given a great deal of thought, and don’t really have time to,
but it popped into my mind today, so I decided to just throw it out
there.

T.

2

On 3/13/06, Trans [email protected] wrote:

Rather then using a specific method for accessing the
singleton/eigennclass, could we just use an alternate to dot-notation.
I.e. Instead of ‘x.eigenclass.foo’ either ‘x:foo’ or ‘x!foo’, or
somthing like that.

I haven’t given a great deal of thought, and don’t really have time to,
but it popped into my mind today, so I decided to just throw it out
there.

As long as we don’t call it “eigenclass”. To pick on your specific
proposal, isn’t x:foo going to be used for selector namespaces? x!foo
looks odd, to me. I’m not opposed to the idea in general, but the
number of sigils in use in Ruby is already high, and I think I’d
prefer a method overall.

-austin

3

I don’t like it. Why do we need special notation? x.eigenclass.foo is
instantly recognizeable. x!foo is nice and short, but it also adds to
the syntax of the language, raising the bar for newcomers.

I don’t suppose that’s necessarily a reason to dismiss it, but I would
err on the side of simplicity unless there’s a really compelling reason
not to. I favor the “and-call” operator because it’s a shortcut to a
really common pattern. I’m not seeing that you need to access the
eigenclass often enough to justify new syntax specifically for it
though.

4

On 3/14/06, [email protected] [email protected] wrote:

though.
Maybe ‘myclass’ or ‘selfclass’ instead of ‘eigenclass’

5

Hi –

On Tue, 14 Mar 2006, Johan Veenstra wrote:

eigenclass often enough to justify new syntax specifically for it
though.

Maybe ‘myclass’ or ‘selfclass’ instead of ‘eigenclass’

Or singleton_class, which is what it’s called :slight_smile:

David

–
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” chapters now available
from Manning Early Access Program! Ruby for Rails

6

Or singleton_class, which is what it’s called :slight_smile:

Really?

x = “A”
=> “A”
irb(main):002:0> x.singleton_class
NoMethodError: undefined method `singleton_class’ for “A”:String
from (irb):2

Yet…

irb(main):003:0> require ‘singleton’
=> true
irb(main):004:0> class A
irb(main):005:1> include Singleton
irb(main):006:1> end
=> A

T.

7

On Mar 13, 2006, at 12:38 PM, Trans wrote:

Rather then using a specific method for accessing the
singleton/eigennclass, could we just use an alternate to dot-notation.
I.e. Instead of ‘x.eigenclass.foo’ either ‘x:foo’ or ‘x!foo’, or
somthing like that.

When I first encountered singleton class notation in Ruby:

class <<obj; end

I thought of ‘<<’ in this situation as a prefix operator on the object.
I suppose you hack the parser to understand that but I’m guessing it
would really tangle up the grammar. In any case, the parser doesn’t
treat
the text after the ‘class’ keyword as an expression. You can’t
substitute
‘<<obj’ for an expression that evaluates to an eigenclass. I always
thought
that was strange. Why doesn’t the parser just look for an expression
that
evaluates to a class object? The superclass can be specified by an
expression,
why can’t the ‘regular’ class be handled in the same way?

In any case, I think that ‘<<obj’ is seems out of place relative
to the rest of Ruby’s syntax.

I’d prefer a method to access the singleton class object:

obj.singleton_class

is OK but I tend to like more terse names:

obj.sclass

If we had this, I would expect:

class obj.sclass
end

to do the obvious thing and open up obj’s singleton class.

Gary W.

8

Hi –

On Tue, 14 Mar 2006, Trans wrote:

Or singleton_class, which is what it’s called :slight_smile:

Really?

x = “A”
=> “A”
irb(main):002:0> x.singleton_class
NoMethodError: undefined method `singleton_class’ for “A”:String
from (irb):2

I didn’t mean there was such a method (though I hope there will be,
as per RCR 231).

David

–
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” chapters now available
from Manning Early Access Program! Ruby for Rails

9

Hi –

On Wed, 15 Mar 2006, [email protected] wrote:

I thought of ‘<<’ in this situation as a prefix operator on the object.

I know it sounds minor but I think with the space it’s much clearer
that this isn’t the case:

class << obj

I’ve always thought of this as sort of pulling the class out of the
object, or something.

to the rest of Ruby’s syntax.

class obj.sclass
end

to do the obvious thing and open up obj’s singleton class.

I’m certainly a Kernel#s[ingleton_]class advocate, but I don’t think
it’s obvious that this change in the behavior of the class keyword
would follow, since:

class some_class_in_a_variable

doesn’t work. I don’t know the reasoning behind it.

David

–
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” chapters now available
from Manning Early Access Program! Ruby for Rails

10

On Mar 14, 2006, at 10:44 AM, [email protected] wrote:

I’m certainly a Kernel#s[ingleton_]class advocate, but I don’t think
it’s obvious that this change in the behavior of the class keyword
would follow, since:

class some_class_in_a_variable

doesn’t work. I don’t know the reasoning behind it.

Yes. My comment regarding expressions after the ‘class’ keyword
was a more general comment on the syntax/semantics of a class/end block
than anything specific to singleton class notation.

I just find the semantics/syntax of the ‘class’ keyword a bit strange.

Here is another example:

(class A; self; end)

is not a valid expression in a method definition but:

(class << obj; self; end)

is just fine. And as I said earlier, Ruby is quite happy to have an
expression as the superclass such as:

class ProxyArray < DelgateClass(Array)
end

I would think that

class expression
   #code
end

would be analogous to

expression.class_eval { # code }

Gary W.

11

That’s an interesting view point Gary. Hadn’t thouhgt of it that way. I
agree that ‘<<’ always stuck out like a sore thumb to me too. One would
think it is an operator. But it’s more like ‘class<<’ is a keyword.
Odd.

I like how your idea lends itself to using variables for classes in the
syntax, which David points out doesn’t work presently --but I don’t see
why it couldn’t.

OTOH, using the YAS (Yet Another Sigil) idea I suggested,

class obj!
end

Is bit interesting too. But maybe everyone’s right about introducing
YAS.

Speaking of “sigil” that gives me a notion.

obj.sigclass

or just

obj.sig

Where ‘sig’ of course means ‘special interest group’. Hey, it’s got the
right meaning. :slight_smile:

T.

12

On Mar 14, 2006, at 10:44 AM, [email protected] wrote:

I know it sounds minor but I think with the space it’s much clearer
that this isn’t the case:

class << obj

This has problems also. Too me it now looks like << is a binary
operator with class and obj as its operands. Or it might be that
class is the receiver of the ‘<<’ message and obj is the single
argument. Trans mentioned that it is more like the ‘<<’ is part
of the keyword as in:

class<<  obj

Which suggests yet another variation of:

sclass obj
end

or
singleton obj
end

But that of course introduces another keyword whereas
Kernel#singleton_class just introduces another method.

I guess the beauty of ‘<<’ is in the eye of the beholder.

Gary W.

13

Quoting Gary W. [email protected]:

   end

[should] be analogous to

   expression.class_eval { # code }

The above example illustrates exactly why general expressions aren’t
allowed as the “operand” for the class keyword. There’d be an
ambiguity around:

class SomeConstant < some_expression
end

…is SomeConstant the name of a new class to define, and the result
of some_expression its superclass?

…or is SomeConstant an object on which to call #<, and the result
of some_expression the argument to the call?

You can’t simultanously have a special syntax for class declaration,
and still allow general expressions, without writing a really
tortured grammar and deeply confusing people in the process.

matz wisely opted to stick with just one – the former – which is
the standard notation for class declarations we use every day.

-mental

14

I wonder what syntax a language designer would come up with if
they weren’t limited to ASCII punctuation. Sometimes I think we
overload the limited punctuation in ASCII beyond its carrying capacity.

You get APL, the original language of choice for one-liners.

15

On Mar 14, 2006, at 5:54 PM, [email protected] wrote:

The above example illustrates exactly why general expressions aren’t
allowed as the “operand” for the class keyword. There’d be an
ambiguity around:

class SomeConstant < some_expression
end

Ah! Yes. That funny thing over my head is a light bulb.
Thanks for pointing out that which is now entirely obvious.

I wonder what syntax a language designer would come up with if
they weren’t limited to ASCII punctuation. Sometimes I think we
overload the limited punctuation in ASCII beyond its carrying capacity.

Gary W.

16

class SomeConstant < some_expression
end

That’s a good point. But we should be clear. First, this is only
ambiguious for constants. Moreover, the above is equivalent to
redefining the value of the constant. I.e.

SomeConstant = Class.new(some_expression)

So it would not matter anyway --in other words, using a superclass is
pointless when reopening a pre-existent class, so this statement must
be defining a class called SomeConstant. There’s really no ambiguity.

The only ambiguity left then is when trying to reopen pre-existent
class (hence no superclass given), singleton or not.

SomeConstant = Class.new
class SomeConstant
end

But here again is it really ambigious? Obviously Ruby can see the
constant is already defined. Therefore this is obviously not trying to
define a new class and the constant should indeed be evaluated --sure
enough it reference a class. Again no ambiguity.

At first glance it seems like a problem. But upon deeper inspection
there doesn’t seem to be one.

T.

17

Hi –

On Wed, 15 Mar 2006, Gary W. wrote:

Yes. My comment regarding expressions after the ‘class’ keyword

(class << obj; self; end)

is just fine.

Either is fine:

irb(main):001:0> def x; class << String; self; end; end
=> nil
irb(main):002:0> x
=> #Class:String

end

would be analogous to

expression.class_eval { # code }

Do you mean you’d like the class keyword not to start a new local
scope?

David

–
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” chapters now available
from Manning Early Access Program! Ruby for Rails

18

Hi,

In message “Re: Alternate notation for eigenclass”
on Wed, 15 Mar 2006 11:22:22 +0900, [email protected] writes:

|Of course all of this may change if the use of classes to implement
|per-object behavior changes. I think that’s why Matz hasn’t wanted to
|have a singleton_class method (i.e., it couples the concept to much to
|the implementation).

It was the original reason. But I changed my mind. The only reason
we don’t have eigenclass (or singleton_class) method is absence of the
best name, which 100% suitable for the concept.

						matz.
19

Hi –

On Wed, 15 Mar 2006, Gary W. wrote:

argument. Trans mentioned that it is more like the ‘<<’ is part
of the keyword as in:

class<< obj

I guess I think of, say:

C

and

<< obj

as two class-invoking expressions (one by name, one anonymous), with
the class keyword able to handle either type of expression.

Which suggests yet another variation of:

sclass obj
end

or
singleton obj
end

Of course all of this may change if the use of classes to implement
per-object behavior changes. I think that’s why Matz hasn’t wanted to
have a singleton_class method (i.e., it couples the concept to much to
the implementation).

David

–
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

“Ruby for Rails” chapters now available
from Manning Early Access Program! Ruby for Rails

20

On Mar 14, 2006, at 9:17 PM, [email protected] wrote:

On Wed, 15 Mar 2006, Gary W. wrote:

Either is fine:

irb(main):001:0> def x; class << String; self; end; end
=> nil

A singleton class/end block is parsed and evaluated as an expression.
But a regular class/end block is not accepted by the parser:

irb(main):012:0> def x; (class A; self; end); end
SyntaxError: compile error
(irb):12: class definition in method body
def x; (class A; self; end); end
^
from (irb):12
irb(main):013:0>

Do you mean you’d like the class keyword not to start a new local
scope?

No, I realize the scoping rules are different and useful. I was
just pointing out how the Ruby parser forbids expressions after the
class keyword. If Kernel#singleton_class was defined I had in my mind
that you could replace:

class << obj
end

with
class obj.singleton_class
end

if you allowed an expression after the class keyword thus getting
rid of the << syntax which seems ‘foreign’ to me relative to the rest
of the Ruby syntax.

Anyway, [email protected] pointed out the ambiguity that would create
with respect to parsing an arbitrary expression vs. the ancestor
declaration syntax (Sub < Super).

So even with Kernel#singleton_class you would still need to use
the ‘class << obj’ notation if you want to open the singleton class
and avoid creating a closure as occurs with the block syntax.

Gary W.