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.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-03-13 18: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.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-03-13 19:26
(Received via mailing list)
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.

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
41c597a48c80e37ba68d1adc7095ea0e?d=identicon&s=25 unknown (Guest)
on 2006-03-14 05: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.
Ff7c333574fd4cd19f5925f6c71abda5?d=identicon&s=25 Johan Veenstra (Guest)
on 2006-03-14 09:14
(Received via mailing list)
On 3/14/06, ssmoot@gmail.com <ssmoot@gmail.com> wrote:
> though.
Maybe 'myclass' or 'selfclass' instead of 'eigenclass'
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-14 15: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 (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
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-03-14 15: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.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-14 15: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 (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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-14 16: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 Wright
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-14 16:45
(Received via mailing list)
Hi --

On Wed, 15 Mar 2006, gwtmp01@mac.com 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 (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
9c1018f025d0c39fdf2158f1be358502?d=identicon&s=25 Gary Wright (Guest)
on 2006-03-14 22:43
(Received via mailing list)
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.

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
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-03-14 22: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.
9c1018f025d0c39fdf2158f1be358502?d=identicon&s=25 Gary Wright (Guest)
on 2006-03-14 23:26
(Received via mailing list)
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

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
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-03-14 23:54
(Received via mailing list)
Quoting Gary Wright <wright_gary_r@sbcglobal.net>:

>        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
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-15 00:28
(Received via mailing list)
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

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
7df03228fdadcf3bc7b10439e4e7e1fd?d=identicon&s=25 1337p337 (Guest)
on 2006-03-15 01: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
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-03-15 02: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.
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-15 03:19
(Received via mailing list)
Hi --

On Wed, 15 Mar 2006, Gary Wright 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 (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
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-15 03:22
(Received via mailing list)
Hi --

On Wed, 15 Mar 2006, Gary Wright 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 (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
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2006-03-15 03:35
(Received via mailing list)
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.
25e11a00a89683f7e01e425a1a6e305c?d=identicon&s=25 Wilson Bilkovich (Guest)
on 2006-03-15 04:57
(Received via mailing list)
On 3/14/06, Yukihiro Matsumoto <matz@ruby-lang.org> 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?
E7559e558ececa67c40f452483b9ac8c?d=identicon&s=25 unknown (Guest)
on 2006-03-15 07:58
(Received via mailing list)
On Mar 14, 2006, at 9:17 PM, dblack@wobblini.net wrote:
> On Wed, 15 Mar 2006, Gary Wright 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, 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
47b1910084592eb77a032bc7d8d1a84e?d=identicon&s=25 Joel VanderWerf (Guest)
on 2006-03-15 08:10
(Received via mailing list)
Wilson Bilkovich 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.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-03-15 15: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.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 Trans (Guest)
on 2006-03-15 15:16
(Received via mailing list)
> Anyway, men...@rydia.net 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.
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-03-15 18:29
(Received via mailing list)
Quoting Wilson Bilkovich <wilsonb@gmail.com>:

> Intrinsic Class, Innate Class.

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

-mental
1fba4539b6cafe2e60a2916fa184fc2f?d=identicon&s=25 unknown (Guest)
on 2006-03-15 18:38
(Received via mailing list)
Hi --

On Thu, 16 Mar 2006, mental@rydia.net wrote:

> Quoting Wilson Bilkovich <wilsonb@gmail.com>:
>
>> 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 (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
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-03-15 19:13
(Received via mailing list)
Quoting Trans <transfire@gmail.com>:

> 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
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 unknown (Guest)
on 2006-03-15 19:19
(Received via mailing list)
Quoting Trans <transfire@gmail.com>:

> 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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 Austin Ziegler (Guest)
on 2006-03-15 20:15
(Received via mailing list)
On 3/15/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
> On Thu, 16 Mar 2006, mental@rydia.net wrote:
>> Quoting Wilson Bilkovich <wilsonb@gmail.com>:
>>> 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.