injecting dynamic methods into a class

[David A. Black]

Hi --

About a year ago, I was having to decide what term to use in Facets, I
included the ususal fair but wan't happy about having to have so many
methods all for the same thing. So I tried to find a more suitable term
that we all could generally agree on. I've tried out a few ideas, but
none of them really worked. Around that time _why the lucky stiff came
up with the term "eigenclass", and that has had some sticking power, no
doubt in part due to the ingenius humor he can bring to things. I think
it a fairly good term, and I think we should keep using it and even get
a bit more serious about it, tough obviously it still lacks in certain
respects.

This subject used to be approached in the spirit of making suggestions to
Matz, to help him in the process of coming up with a good replacement term
for "singleton class" if he decides to replace it. For some reason it's
turned into people not only coining terms but actually using them publicly
as drop-in replacements, unremarked upon, for "singleton class." The
result is that, de facto, there's no term any more, when there used to be
a perfectly serviceable term. Instead there's a kind of smeared rainbow
of terms, and a lot of meta-explanations about why there's a smeared
rainbow instead of a term.

It's regrettable that the thing singled out for this strange treatment is
something that's often quite difficult for Ruby learners to understand
anyway. Having to learn not only the mechanics of singleton classes, but
also a bunch of Ruby community lore about who uses what term, just so that
one can understand what various people are saying, seems to me to be
pretty tiresome.

Oh well -- obviously the shipped has sailed on this. I just hope that if
Matz does make some kind of decision about it, people will actually pay
attention to it.


David

__
David A. Black
(e-mail address removed)

"Ruby for Rails", forthcoming from Manning Publications, April 2006!

 

[Ross Bamford]

I know I'm new, but humour me if you will ?
Firstly, what's wrong with 'singleton'?

[snippage]

It doesn't really bother me. But there is some confusion with
the Singleton pattern, and with other similar usages.

Now I've spent some time with the lingo, I'm not especially bothered
either. But when I first started reading Ruby it was confusing enough to
make me think twice about learning ocaml instead. I see the confusion with
Singleton, but to be honest it felt 'right-ish' to me nevertheless. I was
searching around trying to find out what an Eigenclass was, and when I
found it described as 'singleton class' that set me on the right road. It
doesn't exactly fit, but it's not a million miles away either.

Some people want to change it, I think. If it must be changed, I
would favor something like "singular class" (and I agree with your
assessment of "ad hoc"). Some have suggested "eigenclass" -- and I
admit this is a cool-sounding word, reminding me of my math and physics
(and German) in college. But I can't really advocate it seriously.

Eigenclass is definitely l337er Singular class could work I think, for
the reason I mentioned above - it's the idea that it applies to a single
instance. Metaclass also seems to fit, but again I think the meaning of
meta is being gradually relaxed by popular usage (much like ad-hoc I
guess, but the other way around).

Whatever happens I hope the powers that be bear in mind that Ruby is
becoming ever more widespread, so whatever ends up being chosen needs to
in some way lead the newbie to the idea of a class that applies to an
object (instance class? Seems like a contradiction in terms...)

 

[Ross Bamford]

There has been much discussion about this. The problem with the term
singleton is that it clashes with singleton design pattern, which is
something different altogether. B/c of this much discussion has been
given to finding a better term.

I had the feeling this was something of an ongoing issue from the
discussion I've seen here

Now, The original term I believe was "virtual class", indeed you will
still find an error or two in core that uses that phrase. I'm not sure
you will find the term "singleton" anywhere in the source though. Also
the the term "metaclass" was used when the context is of a class' or
module's singleton class. But metaclass fell out of favor --I think
b/c matz said he didn't like it. So "singleton" came along to sort of
fill the void, not so much for its particular merits, but more for the
lack of something better. Also I point out we have other terms that can
cause confusion, although they too refer to the same thing just in a
particular usage, namely "class methods" and "module methods".

I think Metaclass could have been a contender, but then again it too could
mean a variety of things I suppose. Absolutely agree about other terms
causing confusion, but I've not seen that many that seemed _intended_ to
cause confusion, like eigenclass (I'm not saying that is the case, just
that it appeared that way from a rank newbie perspective).

You see that's not the actual definition of the term. That's more of
the vague understanding one gathers from not actually knowing the
meaning. Although that vague idea has become widespread enough to be
acknolwedged, it is still a secondary usage. I understand where you're
coming from though, b/c I thought much the same way until I had used
the word inproperly and my Grandmother corrected me. I wasn't so sure,
so we looked it up in the dictionary and sure enough she was right. The
definition is quite clear. From Websters (and others):

Main Entry: 1ad hoc
Pronunciation: 'ad-'häk, -'hOk; 'äd-'hOk
Function: adverb
Etymology: Latin, for this
: for the particular end or case at hand without consideration of
wider application

That's how I realized the term would make a good fit.

I probably got that the wrong way around at 2am You're right of course
that ad-hoc's primary definition relates to a vertical solution, but still
I think that the secondary definition has been around for long enough
(even if based on popular misuse/misconception), and in fact probably
carries more weight in most people's minds

If "Car manufacturer X has an ad-hoc safety testing system", would you buy
the '06 model 'X' Voyager? Even if it means they put their test rig
together specifically to test safety of that model, the negative
connotations of the word kind of bury that in the popular view, I think.

I did a survey once and people's opinions are all over the map. I
personaly would like to see a solid term. I think 'adhoc' works well
becuase it is small, ponient and has the added advantage (which none of
the other choices have) of being an adverb, so it has very flexible
usage. I guess my end preference to all this is that we migrate to the
terms 'adhoc' and 'eigenclass' as is suitable. But I think this will
happen naturally if the terms work.

Definitely agree it's important to find a solid term, and stick to it, and
I can see why you like these terms, but I think if Ruby is going to
continue going from strength to strength (and I hope it will!) something
less esoteric should be chosen (no, I don't know what. It's easy to
criticise but when it comes to suggesting alternatives ... ).

Perhaps it's something that only decisive action by the powers that be in
Ruby can really settle...

 

[Trans]

This subject used to be approached in the spirit of making suggestions to
Matz, to help him in the process of coming up with a good replacement term
for "singleton class" if he decides to replace it. For some reason it's
turned into people not only coining terms but actually using them publicly
as drop-in replacements, unremarked upon, for "singleton class." The
result is that, de facto, there's no term any more, when there used to be
a perfectly serviceable term. Instead there's a kind of smeared rainbow
of terms, and a lot of meta-explanations about why there's a smeared
rainbow instead of a term.

It's regrettable that the thing singled out for this strange treatment is
something that's often quite difficult for Ruby learners to understand
anyway. Having to learn not only the mechanics of singleton classes, but
also a bunch of Ruby community lore about who uses what term, just so that
one can understand what various people are saying, seems to me to be
pretty tiresome.

Oh well -- obviously the shipped has sailed on this. I just hope that if
Matz does make some kind of decision about it, people will actually pay
attention to it.

Well, I think matz has never made a fird decision on it, and it seems
has prefered to let the ciommunity sort it out, as is evidence by the
fact the the source still referes to "virtual class", another perfectly
servicable term but one I think you yourself objected too b/c of it's
overlap with virtual classes in c.

T.

 

[Trans]

s/fird/firm/

 

[David A. Black]

Hi --

Well, I think matz has never made a fird decision on it, and it seems
has prefered to let the ciommunity sort it out, as is evidence by the
fact the the source still referes to "virtual class", another perfectly
servicable term but one I think you yourself objected too b/c of it's
overlap with virtual classes in c.

I don't know what you mean about Matz not having made a firm decision.
Was he under some deadline, imposed by you? Did he say, "Call singleton
classes lots of different things, when discussing Ruby with newcomers, and
let's have some kind of vulgar pseudo-Darwinian contest to see whose usage
outnumbers everyone else's"?

Or did he lose his right to make a decision at all because he hasn't
cleansed the source of the term "virtual class" and you caught him at it?
(Like a game of "Simon Says" -- "You said 'virtual class' -- you're out!")
Does every inconsistency or ambiguity in the source indicate something
that Matz "prefers to let the community sort out"?

These are rhetorical questions; your answers to them are actually already
present in what you've written. My main goal is to suggest to others that
the growth of Ruby does not *have* to mean a growing disconnect between
the community and Matz, or the community and a set of traditional
practices (including the practice of discussing things with Matz and
taking an interest in what he says). What we've got *can* scale, with a
little care and attention.


David
__
David A. Black
(e-mail address removed)

"Ruby for Rails", forthcoming from Manning Publications, April 2006!

 

[Trans]

Okay David, its obvious you're getting upset. Though you say the
questions are rhetorical, they nonetheless have a very simple answer:

I ASKED MATZ AND HE HAD NO ANSWER.

What am I suppose to think then? Don't you recall the conversation? It
wan't that long ago. In fact I think it was in that thread _why first
came up with the term 'eigenclass', or at least the first I had heard
of it. And at the tiem I was suggesting the term "special class".

So I dont know where you gettting this disconnect between matz and
community. I asked matz, Matz has participated, but obviously he's not
sure either or he would have made it clear. If Matz wanted to, he could
easily step in at anytime and say "Hey, enough. This is what we call
it". Right? Maybe he will eventually, but in the mean time I don't see
anything wrong with trying out alternatives. We all know that the term
'singleton' has a semantic overlap problem, as is once again
demonstrated by Johnathans post to this thread. Go back and read it. So
lets keep trying out the possibilites. If for instance you really like
"own" then use it see if it sticks. Short of Matz making an edict, I
don't see how else it can get worked out.

T.

 

[David A. Black]

Hi --

Okay David, its obvious you're getting upset. Though you say the
questions are rhetorical, they nonetheless have a very simple answer:

I ASKED MATZ AND HE HAD NO ANSWER.

What am I suppose to think then? Don't you recall the conversation? It
wan't that long ago. In fact I think it was in that thread _why first
came up with the term 'eigenclass', or at least the first I had heard
of it. And at the tiem I was suggesting the term "special class".

So I dont know where you gettting this disconnect between matz and
community. I asked matz, Matz has participated, but obviously he's not
sure either or he would have made it clear. If Matz wanted to, he could
easily step in at anytime and say "Hey, enough. This is what we call
it". Right? Maybe he will eventually, but in the mean time I don't see
anything wrong with trying out alternatives. We all know that the term
'singleton' has a semantic overlap problem, as is once again
demonstrated by Johnathans post to this thread. Go back and read it. So
lets keep trying out the possibilites. If for instance you really like
"own" then use it see if it sticks. Short of Matz making an edict, I
don't see how else it can get worked out.

I almost literally can't believe my answer to this isn't clear from what
I've already said, but in case not, the answer is: use the standard (if
sometimes problematic) term, and don't set deadlines for Matz. To say
that Matz is "not sure", and that therefore all bets are off, just because
he hasn't made a change, is wrong.

I don't *want* to go around talking about "own classes". I don't *want*
to introduce coinages into Ruby discourse in the hope that people will
think they're conventional terms that other people will understand, when
they aren't. "Trying out the possibilities" means muddying the waters and
confusing newcomers. I don't want to do that either, to the extent I can
help it.


David
__
David A. Black
(e-mail address removed)

"Ruby for Rails", forthcoming from Manning Publications, April 2006!

 

[Trans]

Hi --



I almost literally can't believe my answer to this isn't clear from what
I've already said, but in case not, the answer is: use the standard (if
sometimes problematic) term, and don't set deadlines for Matz. To say
that Matz is "not sure", and that therefore all bets are off, just because
he hasn't made a change, is wrong.

I don't *want* to go around talking about "own classes". I don't *want*
to introduce coinages into Ruby discourse in the hope that people will
think they're conventional terms that other people will understand, when
they aren't. "Trying out the possibilities" means muddying the waters and
confusing newcomers. I don't want to do that either, to the extent I can
help it.

Standards? Alright genius, why don't you use the the term "virtual
class" then? After all that's what it says in the source code -- and
you can't get any more standard than that. But I remember cleary you
going-on, "Please not virtual class!", and how terrible it was becuase
of it's sematic overlap with the kind in c. Well, I have the same
problem with singleton, and worse because both kinds exist in Ruby. I
never like using the term becuase I always feel like I need to put a
dang parenthecal explination after it. Why is your trouble more
important than the other? --Indeed, on reflection, it seems that
people stopped using "virtual" b/c of your request. Hmmm...I wonder
what term they use in Japanese?

Anyway, I'm sorry there was all this fuss. The term adhoc works as a
general lingusitic modifier with the appropriate meaning, whether its
is a "standard" term or not, and I will use it as such --a
singleoton/eigen/meta/virtual class, whatever you call it, is very much
adhoc.

T.

 

[David A. Black]

Hi --

Standards? Alright genius, why don't you use the the term "virtual
class" then? After all that's what it says in the source code -- and
you can't get any more standard than that. But I remember cleary you
going-on, "Please not virtual class!", and how terrible it was becuase
of it's sematic overlap with the kind in c.

My problem with virtual is that singleton classes aren't virtual.

Well, I have the same problem with singleton, and worse because both
kinds exist in Ruby. I never like using the term becuase I always feel
like I need to put a dang parenthecal explination after it. Why is your
trouble more important than the other? --Indeed, on reflection, it
seems that people stopped using "virtual" b/c of your request. Hmmm...I
wonder what term they use in Japanese?

You're mixing up two things. I have no problem with discussing the merits
of all these terms. As you say, I've been involved in these discussions
already, and I imagine I will continue to be.

What I don't like is jumping ship from the whole discussion process,
because Matz's supposed time-limit has expired (or whatever), and just
starting to use a term in the hope that it will "take".

Anyway, I'm sorry there was all this fuss. The term adhoc works as a
general lingusitic modifier with the appropriate meaning, whether its
is a "standard" term or not, and I will use it as such --a
singleoton/eigen/meta/virtual class, whatever you call it, is very much
adhoc.

Singleton classes are also (one finds) "puzzling" to a lot of people. I
would not like to see a sect of people saying that "every object has a
'puzzling class'".

There's got to be more to this than everyone coming up with an adjective
that he or she finds apt and using it.


David
__
David A. Black
(e-mail address removed)

"Ruby for Rails", forthcoming from Manning Publications, April 2006!

 

[Joel VanderWerf]

There's got to be more to this than everyone coming up with an adjective
that he or she finds apt and using it.

Maybe we should just call it the "double left angle bracket" class, as
long as that's the syntax for it

 

[gwtmp01]

You're mixing up two things. I have no problem with discussing the
merits
of all these terms. As you say, I've been involved in these
discussions
already, and I imagine I will continue to be.

Just for the record, IMHO:

virtual class:
too much semantic overlap with C++ usage
generally assumed to be associated with a *class* (not an
arbitrary object)

meta class:
meta, as an adjective, is too vague
generally assumed to be associated with a *class* (not an
arbitrary object)

singleton class:
has the wrong semantic 'direction' (from class to object)
probably because:
too much semantic overlap with the singleton pattern
easily confused with the specific Singleton class in the standard
library

adhoc class:
too many negative connotations despite the useful latin root

eigen class:
has the right semantic 'direction' (from object to class)
'eigen', as a prefix/adjective, has an clear meaning that matches
the
semantics of (class <<self; self; end)
long history of use in science, math, etc.
it is easier to type object.eclass than (class <<object; self; end)


P.S. I think one of the reasons we all still type (class <<object;
self; end)
is that the terminology for the concept isn't "solid" yet. Until you
have
a solid, short, clear name it is pretty hard to add a standard method
to Object
that returns this 'thing' we are talking about.


Gary Wright

 

[MenTaLguY]

--=-0n8fVLUgEuGU1Jg8Qfuq
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

There's got to be more to this than everyone coming up with an adjective
that he or she finds apt and using it.

I don't know, man. Personally at this point I think we should stand
back and let natural selection do its thing.

-mental

--=-0n8fVLUgEuGU1Jg8Qfuq
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDlgElcUNIGiXCc4MRAkpQAJ4pxw5IP0+ZUfcbqD+uy03fgktQXgCgmPB6
cnwkAWzHnL8IAe1wkTDmjdo=
=KxcQ
-----END PGP SIGNATURE-----

--=-0n8fVLUgEuGU1Jg8Qfuq--

 

[David A. Black]

Hi --

I don't know, man. Personally at this point I think we should stand
back and let natural selection do its thing.

Natural selection isn't connected to what we're talking about. If you
mean we should ignore Matz, or find a way to coerce him into changing his
terminology to match a bunch of Google searches -- while, meanwhile, a lot
of newcomers to Ruby suffer because of how cool people think their names
for singleton classes are -- then I don't think you've got a sound or
respectful plan.


David
__
David A. Black
(e-mail address removed)

"Ruby for Rails", forthcoming from Manning Publications, April 2006!

 

[MenTaLguY]

--=-RsWsOVxl/KnBAaKXkn9l
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Natural selection isn't connected to what we're talking about. If you
mean we should ignore Matz, or find a way to coerce him into changing his
terminology to match a bunch of Google searches

I think the disadvantages to the alternate terminology have been laid
out pretty clearly in this thread already. People can make informed
decisions.

People are going to do what they want. Neither you nor I (nor even
Matz, really) can control that. Ruby is a living culture, with give and
take and evolving terminology.

-- while, meanwhile, a lot of newcomers to Ruby suffer because of how
cool people think their names for singleton classes are -- then I don't
think you've got a sound or respectful plan.

Plan? I'm just being realistic.

I've been close to a few ill-fated open source projects where the
prevailing attitude was that insisting on anything different from what
the project founder specifies is disrespectful and destructive. That
attitude was deadly.

I've also been involved with a few projects (and cofounded one --
Inkscape) which were wildly successful, growing organically and
developing broad communities. People were free to do their own thing,
and yet the project leaders were more respected. Sometimes things do
get messy and confusing, but in my experience, even those messy and
confusing things work out in the end.

[ I'll leave it to others to decide which description better fits
Ruby. ]

I'm not a Taoist, but I think the notion of "striving-without-striving"
describes the necessary ethic nicely. Relax. This is not about control
or respect or disrespect or the Ultimate Fate of Ruby.

-mental

--=-RsWsOVxl/KnBAaKXkn9l
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDlkaNcUNIGiXCc4MRAjvfAJ4l3CDgBoMwFVWbSM82t7PM6jOHbgCfVm2P
HnXPBzAopUhpeva6rrKVMcQ=
=hGgz
-----END PGP SIGNATURE-----

--=-RsWsOVxl/KnBAaKXkn9l--

 

[MenTaLguY]

--=-l/6oPqBL2BRNPduGCpwc
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

People were free to do their own thing, and yet the project
leaders were more respected.

And, lest this be misconstrued, I don't think this is at all
incompatible with "benevolent dictator" roles.

The thing about benevolent dictators in the mode of e.g. Linus or Matz
is that there is is an essential freedom to their rule -- people follow
them not because they are forced or obligated to, but because they want
to. That also means occasionally people won't. Life goes on.

Matz fashions Ruby as he will, and people come to him because it is
good.

-mental

--=-l/6oPqBL2BRNPduGCpwc
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDlktycUNIGiXCc4MRAmMBAJ92WAwiwPqZiF3N2KNV+zjOkYujOACgpNkv
nrd7bZz55UOr+A+2ou0d53E=
=JOal
-----END PGP SIGNATURE-----

--=-l/6oPqBL2BRNPduGCpwc--

 

[dblack]

Hi --

Plan? I'm just being realistic.

Absolutely. As I said in my second or so post about this, the ship
has sailed; it's obvious that, for whatever reason, singleton classes
*are* going to be called all sorts of different things. I just think
it's too bad.

I've been close to a few ill-fated open source projects where the
prevailing attitude was that insisting on anything different from what
the project founder specifies is disrespectful and destructive. That
attitude was deadly.

Again (last time?), I'm not saying that nothing should change -- just
that short-circuiting the discussion/decision process (which does
exist, and which has a track-record of working well for Ruby) is
short-sighted.

I could, for example, set up a web page that described Ruby as an
"item-oriented" language: everything is an "item", the class Object is
misnamed but Matz hasn't stepped in to correct so I have to, etc. I
could probably manage to confuse a few newcomers. But it wouldn't be
good. (It's a hyperbolic example, but still.)

I've also been involved with a few projects (and cofounded one --
Inkscape) which were wildly successful, growing organically and
developing broad communities. People were free to do their own thing,
and yet the project leaders were more respected. Sometimes things do
get messy and confusing, but in my experience, even those messy and
confusing things work out in the end.

[ I'll leave it to others to decide which description better fits
Ruby. ]

I don't think it's necessary to pigeon-hole Ruby philosophically. I
just wish people would let Matz decide what these classes should be
called. (And remember that Matz's style of deciding *includes*
community input; by looking to Matz, I am not subscribing to some
philosophy of centralized power [believe me :-].) It's really a
rather circumscribed point.

It's worth noting that a result of Matz's style of development, as
well as the contributions of the community, there actually aren't very
many things in the language that are vulnerable to this kind of
treatment. Singleton classes seem to be the magnet for it.

I'm not a Taoist, but I think the notion of "striving-without-striving"
describes the necessary ethic nicely. Relax. This is not about control
or respect or disrespect or the Ultimate Fate of Ruby.

Right -- it's about what to call singleton classes, and I wish people
would discuss it and then let Matz decide. Maybe he'll decide that
the best thing is arbitrarily many terms, and then lots of people will
be a little bit happy


David

 

[Yukihiro Matsumoto]

Hi,

In message "Re: injecting dynamic methods into a class"

|Okay David, its obvious you're getting upset. Though you say the
|questions are rhetorical, they nonetheless have a very simple answer:
|
| I ASKED MATZ AND HE HAD NO ANSWER.

Perhaps, I was drawn in the flood of ruby-talk mails (and spams).

I already abandoned the term "virtual class", and have removed the
term from the CVS head. It still remains in 1.8 source just for
compatibility. I am using the term "singleton class", and I will use
it until we find the better term as I said in [ruby-talk:141548]
7 months ago in the famous Ilias thread. I'm not sure yet that
"eigenclass" is the one, although it sounds cool. I think we can wait
to see how it goes.

matz.

 

[Trans]

Hi,

In message "Re: injecting dynamic methods into a class"

|Okay David, its obvious you're getting upset. Though you say the
|questions are rhetorical, they nonetheless have a very simple answer:
|
| I ASKED MATZ AND HE HAD NO ANSWER.

Perhaps, I was drawn in the flood of ruby-talk mails (and spams).

Yes, that happens sometimes doesn't it. But I didn't mean that you
_didn't answer_ I recall your participation in those conversations. I
just meant that you didn't specify a certain term.

I already abandoned the term "virtual class", and have removed the
term from the CVS head. It still remains in 1.8 source just for
compatibility. I am using the term "singleton class", and I will use
it until we find the better term as I said in [ruby-talk:141548]
7 months ago in the famous Ilias thread. I'm not sure yet that
"eigenclass" is the one, although it sounds cool. I think we can wait
to see how it goes.

That's very clear. Thank you.

T.

 

[James Britt]

Standards? Alright genius, why don't you use the the term "virtual
class" then?

Can we keep this civil?

Disagree all you like with David and his line of thought; I'm stunned,
though, that anyone who has spent *any* time on this list would consider
insulting him or his reasoning ability.

It's just wrong, Trans.


James


--

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools