Forum: Ruby Alternate notation for eigenclass

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Trans (Guest)
on 2006-03-13 19:40
(Received via mailing list)
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.
Austin Z. (Guest)
on 2006-03-13 20:26
(Received via mailing list)
On 3/13/06, Trans <removed_email_address@domain.invalid> 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
unknown (Guest)
on 2006-03-14 06:29
(Received via mailing list)
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.
Johan Veenstra (Guest)
on 2006-03-14 10:14
(Received via mailing list)
On 3/14/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> though.
Maybe 'myclass' or 'selfclass' instead of 'eigenclass'
unknown (Guest)
on 2006-03-14 16:29
(Received via mailing list)
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 :-)


David

--
David A. Black (removed_email_address@domain.invalid)
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
Trans (Guest)
on 2006-03-14 16:41
(Received via mailing list)
> Or singleton_class, which is what it's called :-)

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.
unknown (Guest)
on 2006-03-14 16:41
(Received via mailing list)
Hi --

On Tue, 14 Mar 2006, Trans wrote:

>> Or singleton_class, which is what it's called :-)
>
> 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 (removed_email_address@domain.invalid)
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
unknown (Guest)
on 2006-03-14 17:21
(Received via mailing list)
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.
unknown (Guest)
on 2006-03-14 17:45
(Received via mailing list)
Hi --

On Wed, 15 Mar 2006, removed_email_address@domain.invalid 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 (removed_email_address@domain.invalid)
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
Gary W. (Guest)
on 2006-03-14 23:43
(Received via mailing list)
On Mar 14, 2006, at 10:44 AM, removed_email_address@domain.invalid 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.
Trans (Guest)
on 2006-03-14 23:59
(Received via mailing list)
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. :-)

T.
Gary W. (Guest)
on 2006-03-15 00:26
(Received via mailing list)
On Mar 14, 2006, at 10:44 AM, removed_email_address@domain.invalid 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.
unknown (Guest)
on 2006-03-15 00:54
(Received via mailing list)
Quoting Gary W. <removed_email_address@domain.invalid>:

>        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
unknown (Guest)
on 2006-03-15 01:28
(Received via mailing list)
On Mar 14, 2006, at 5:54 PM, removed_email_address@domain.invalid 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.
1337p337 (Guest)
on 2006-03-15 02:09
(Received via mailing list)
> 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.
http://en.wikipedia.org/wiki/APL_programming_language
Trans (Guest)
on 2006-03-15 03:09
(Received via mailing list)
> 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.
unknown (Guest)
on 2006-03-15 04:19
(Received via mailing list)
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 (removed_email_address@domain.invalid)
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
unknown (Guest)
on 2006-03-15 04:22
(Received via mailing list)
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 (removed_email_address@domain.invalid)
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
Yukihiro M. (Guest)
on 2006-03-15 04:35
(Received via mailing list)
Hi,

In message "Re: Alternate notation for eigenclass"
    on Wed, 15 Mar 2006 11:22:22 +0900, removed_email_address@domain.invalid 
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.
Wilson B. (Guest)
on 2006-03-15 05:57
(Received via mailing list)
On 3/14/06, Yukihiro M. <removed_email_address@domain.invalid> wrote:
> 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.
>

We've already got superclasses and subclasses.  I suppose the
'singleton class' name needs to express its location in that hierarchy
without suggesting any direct relationship?

At the risk of starting another naming thread, what about?:
Overclass, Underclass, Anchorclass, Embedded Class, Intrinsic Class,
Innate Class.

Or, since it's so hard to come up with a word for this, how about
Nameless Class?
unknown (Guest)
on 2006-03-15 08:58
(Received via mailing list)
On Mar 14, 2006, at 9:17 PM, removed_email_address@domain.invalid 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, removed_email_address@domain.invalid 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.
Joel VanderWerf (Guest)
on 2006-03-15 09:10
(Received via mailing list)
Wilson B. wrote:
...
> At the risk of starting another naming thread, what about?:
> Overclass, Underclass, Anchorclass, Embedded Class, Intrinsic Class,
> Innate Class.
>
> Or, since it's so hard to come up with a word for this, how about
> Nameless Class?

Underclass??? It's revolting ;)

Lowerclass? Gotnoclass? sorry.... Being serious starting....now:

UnitClass
AtomClass
SingularClass (that's been discussed, and I like it)
Singularity
BongoClass (named after Matt Groening's rabbit with one ear)

Thus ends my annual participation in the ritual renaming of the Class
with No Name.
Trans (Guest)
on 2006-03-15 16:09
(Received via mailing list)
>Thus ends my annual participation in the ritual renaming of the Class
> with No Name.

:-D

No comment on #sig? Oh my, that must be GOOD sign. :-)

T.
Trans (Guest)
on 2006-03-15 16:16
(Received via mailing list)
> Anyway, removed_email_address@domain.invalid pointed out the ambiguity that would create
> with respect to parsing an arbitrary expression vs. the ancestor
> declaration syntax (Sub < Super).

As I pointed out, there really isn't an ambiguity. BUT that doesn't
mean it's neccessarily nice for the human. Seeing 'class X', one is
inclined to think X is the class, and not normally be concerned whether
X is already defined and thus should evaluated instead.

T.
unknown (Guest)
on 2006-03-15 19:29
(Received via mailing list)
Quoting Wilson B. <removed_email_address@domain.invalid>:

> Intrinsic Class, Innate Class.

It's worth noting that "eigenclass" is synonymous with these.

-mental
unknown (Guest)
on 2006-03-15 19:38
(Received via mailing list)
Hi --

On Thu, 16 Mar 2006, removed_email_address@domain.invalid wrote:

> Quoting Wilson B. <removed_email_address@domain.invalid>:
>
>> Intrinsic Class, Innate Class.
>
> It's worth noting that "eigenclass" is synonymous with these.

Not entirely; for example, objects have lots of innate behaviors that
are not "eigen".  Actually "non-innate" would be closer (and I've
always wanted #birth_class for the original class :-)


David

--
David A. Black (removed_email_address@domain.invalid)
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
unknown (Guest)
on 2006-03-15 20:13
(Received via mailing list)
Quoting T. <removed_email_address@domain.invalid>:

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

Only because you have an a priori idea of what makes sense.

It's easy to insist that a parser should "do what you mean", but try
explaining that to a pushdown automaton...

Try writing some BNF for this part of Ruby's syntax, with your
proposed change.  Then you'll understand.

-mental
unknown (Guest)
on 2006-03-15 20:19
(Received via mailing list)
Quoting T. <removed_email_address@domain.invalid>:

> As I pointed out, there really isn't an ambiguity.

Well, when we're speaking of grammars, "ambiguity" refers to
situations where the formal grammar (by itself) permits more than
one possible interpretation of the same text.

As you point out, in cases like that you can introduce additional
criteria -- extrinsic to the formal grammar -- so they aren't
"real" ambiguities, but it's far better to avoid ambiguous grammars
in the first place.  Unambiguous grammars are much easier to work
with.

> BUT that doesn't mean it's neccessarily nice for the human.

Yeah, that's the other thing.  As I think Terrence pointed out once,
ambiguities correlate strongly to user confusion.

-mental
Austin Z. (Guest)
on 2006-03-15 21:15
(Received via mailing list)
On 3/15/06, removed_email_address@domain.invalid 
<removed_email_address@domain.invalid> wrote:
> On Thu, 16 Mar 2006, removed_email_address@domain.invalid wrote:
>> Quoting Wilson B. <removed_email_address@domain.invalid>:
>>> Intrinsic Class, Innate Class.
>> It's worth noting that "eigenclass" is synonymous with these.
> Not entirely; for example, objects have lots of innate behaviors that
> are not "eigen".  Actually "non-innate" would be closer (and I've
> always wanted #birth_class for the original class :-)

Heh. Well, for my entry in this turn's, I'll make two suggestions:

  #inner_class
  #shadow_class

Or, for the latter, simply:

  #shadow
  #__shadow__

I'm somewhat serious with this one; it's an idea that's sort-of similar
to the idea of an OS/2 shadow.

-austin
This topic is locked and can not be replied to.