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?
Anyway, [email protected] 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.
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
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.
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.
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.
