Alternate notation for eigenclass

ruby-talk
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

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

···

On 3/13/06, Trans <transfire@gmail.com> 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.

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

3

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 Wright

···

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.

4

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.

5

Hi --

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

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.

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

···

On Wed, 15 Mar 2006, gwtmp01@mac.com wrote:

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

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

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

6

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.

7

Maybe 'myclass' or 'selfclass' instead of 'eigenclass'

···

On 3/14/06, ssmoot@gmail.com <ssmoot@gmail.com> wrote:

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.

8

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 Wright

···

On Mar 14, 2006, at 10:44 AM, dblack@wobblini.net 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.

9

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 Wright

···

On Mar 14, 2006, at 10:44 AM, dblack@wobblini.net wrote:

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

  class << obj

10

Hi --

···

On Tue, 14 Mar 2006, Johan Veenstra wrote:

On 3/14/06, ssmoot@gmail.com <ssmoot@gmail.com> wrote:

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.

Maybe 'myclass' or 'selfclass' instead of 'eigenclass'

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

David

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black

11

Quoting Gary Wright <wright_gary_r@sbcglobal.net>:

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

[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

12

Hi --

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.

Either is fine:

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

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 }

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

David

···

On Wed, 15 Mar 2006, Gary Wright wrote:

On Mar 14, 2006, at 10:44 AM, dblack@wobblini.net wrote:

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black

13

Hi --

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

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

···

On Wed, 15 Mar 2006, Gary Wright wrote:

On Mar 14, 2006, at 10:44 AM, dblack@wobblini.net wrote:

--
David A. Black (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black

14

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.

15

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 Wright

···

On Mar 14, 2006, at 5:54 PM, mental@rydia.net 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

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,

···

In message "Re: Alternate notation for eigenclass" on Wed, 15 Mar 2006 11:22:22 +0900, dblack@wobblini.net 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.

18

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>

I would think that

  class expression
     #code
  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?

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, mental@rydia.net 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 Wright

···

On Mar 14, 2006, at 9:17 PM, dblack@wobblini.net wrote:

On Wed, 15 Mar 2006, Gary Wright wrote:

19

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 (dblack@wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

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

20

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.