Alternate notation for eigenclass

T

Trans

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

Austin Ziegler

T24gMy8xMy8wNiwgVHJhbnMgPHRyYW5zZmlyZUBnbWFpbC5jb20+IHdyb3RlOgo+IFJhdGhlciB0
aGVuIHVzaW5nIGEgc3BlY2lmaWMgbWV0aG9kIGZvciBhY2Nlc3NpbmcgdGhlCj4gc2luZ2xldG9u
L2VpZ2VubmNsYXNzLCBjb3VsZCB3ZSBqdXN0IHVzZSBhbiBhbHRlcm5hdGUgdG8gZG90LW5vdGF0
aW9uLgo+IEkuZS4gSW5zdGVhZCBvZiAneC5laWdlbmNsYXNzLmZvbycgZWl0aGVyICd4OmZvbycg
b3IgJ3ghZm9vJywgb3IKPiBzb210aGluZyBsaWtlIHRoYXQuCj4KPiBJIGhhdmVuJ3QgZ2l2ZW4g
YSBncmVhdCBkZWFsIG9mIHRob3VnaHQsIGFuZCBkb24ndCByZWFsbHkgaGF2ZSB0aW1lIHRvLAo+
IGJ1dCBpdCBwb3BwZWQgaW50byBteSBtaW5kIHRvZGF5LCBzbyBJIGRlY2lkZWQgdG8ganVzdCB0
aHJvdyBpdCBvdXQKPiB0aGVyZS4KCkFzIGxvbmcgYXMgd2UgZG9uJ3QgY2FsbCBpdCAiZWlnZW5j
bGFzcyIuIFRvIHBpY2sgb24geW91ciBzcGVjaWZpYwpwcm9wb3NhbCwgaXNuJ3QgeDpmb28gZ29p
bmcgdG8gYmUgdXNlZCBmb3Igc2VsZWN0b3IgbmFtZXNwYWNlcz8geCFmb28KbG9va3Mgb2RkLCB0
byBtZS4gSSdtIG5vdCBvcHBvc2VkIHRvIHRoZSBpZGVhIGluIGdlbmVyYWwsIGJ1dCB0aGUKbnVt
YmVyIG9mIHNpZ2lscyBpbiB1c2UgaW4gUnVieSBpcyBhbHJlYWR5IGhpZ2gsIGFuZCBJIHRoaW5r
IEknZApwcmVmZXIgYSBtZXRob2Qgb3ZlcmFsbC4KCi1hdXN0aW4KLS0KQXVzdGluIFppZWdsZXIg
KiBoYWxvc3RhdHVlQGdtYWlsLmNvbQogICAgICAgICAgICAgICAqIEFsdGVybmF0ZTogYXVzdGlu
QGhhbG9zdGF0dWUuY2EK
 
S

ssmoot

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

Johan Veenstra

------=_Part_17797_456273.1142323867229
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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'

------=_Part_17797_456273.1142323867229--
 
T

Trans

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

gwtmp01

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
 
D

dblack

Hi --

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

--
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! http://www.manning.com/books/black
 
G

Gary Wright

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
 
T

Trans

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

Gary Wright

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
 
D

dblack

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

--
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! http://www.manning.com/books/black
 
D

dblack

Hi --

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

--
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! http://www.manning.com/books/black
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: Alternate notation for eigenclass"
on Wed, 15 Mar 2006 11:22:22 +0900, (e-mail address removed) 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.
 
W

Wilson Bilkovich

Hi,

In message "Re: Alternate notation for eigenclass"
on Wed, 15 Mar 2006 11:22:22 +0900, (e-mail address removed) 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.

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?
 
G

gwtmp01

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, (e-mail address removed) 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
 
J

Joel VanderWerf

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

Trans

Anyway, (e-mail address removed) 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top