Injecting dynamic methods into a class

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

···

On Tue, 6 Dec 2005, Trans wrote:

__
David A. Black
dblack@wobblini.net

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

Ross Bamford wrote:

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.

I'm sure this is an ongoing debate, and I don't want to tread on any beliefs, but I just thought I'd offer a perspective from a fresh pair of eyes. Is there a serious movement to replace 'singleton'?

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 :wink: 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...)

···

On Tue, 06 Dec 2005 03:14:12 -0000, Hal Fulton <hal9000@hypermetrics.com> wrote:

--
Ross Bamford - rosco@roscopeco.remove.co.uk
"\e[1;31mL"

Ross Bamford wrote:

>> ... singleton methods, or adhoc methods (my new prefered
> term).

I know I'm new, but humour me if you will ?

Firstly, what's wrong with 'singleton'? It seems to me that it fits well,
and makes the usage obvious to the reader (well, me, but I assume others
too?).

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

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

Secondly, 'Ad-hoc' seems to be a really odd choice to me. I am
aware that it can be taken to mean 'Specific to a given problem', but it
is also defined along the lines of 'impromtu', 'temporary' or
'disorganized'. Science uses it to mean a quick fix for a flawed theory.
Upon seeing the word ad-hoc I tend to imagine 'jury rigged' - stuck
together with duct tape to last us out the storm.

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 :slight_smile: 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'm sure this is an ongoing debate, and I don't want to tread on any
beliefs, but I just thought I'd offer a perspective from a fresh pair of
eyes. Is there a serious movement to replace 'singleton'?

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 ... :wink: ).

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

···

On Tue, 06 Dec 2005 04:19:03 -0000, Trans <transfire@gmail.com> wrote:

On Tue, 06 Dec 2005 02:10:51 -0000, Trans <transfire@gmail.com> wrote:

--
Ross Bamford - rosco@roscopeco.remove.co.uk
"\e[1;31mL"

David A. Black wrote:

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.

transfire wrote:

'Ad hoc' has too many negative connotations and singleton has a fairly
unambiguous meaning.

I felt the same way at first, until I started using it, keeping in mind
the strict definition --even the Latin definition: *for this*.

That's really interesting. It's unfortunate that the most common use of
the term is a secondary meaning. I guess using it will motivate people
to find out primary meaning. I'm all for it. :slight_smile:

···

--
Posted via http://www.ruby-forum.com/\.

s/fird/firm/

Hi --

David A. Black wrote:
>
> 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.

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

···

On Tue, 6 Dec 2005, Trans wrote:
__
David A. Black
dblack@wobblini.net

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

jonathan wrote:

transfire wrote:

'Ad hoc' has too many negative connotations and singleton has a fairly
unambiguous meaning.

I felt the same way at first, until I started using it, keeping in mind
the strict definition --even the Latin definition: *for this*.

That's really interesting. It's unfortunate that the most common use of
the term is a secondary meaning. I guess using it will motivate people
to find out primary meaning. I'm all for it. :slight_smile:

Just to clarify (I hadn't finished reading all the posts when I made the
above comment). I don't mean to make my vote 'for' this term, but, I
meant that I was for using a term in a way that educates. Most of us
are people that like to learn anyway. :slight_smile:

Having many terms for the same thing isn't necessarily a bad thing. It
happens in every other aspect of programming as well (class methods are
called 'member functions', 'methods', 'member methods', etc.).

How do you all think the term 'static class' fits?

Also, one more thing:

How do you actually implement the singleton pattern in Ruby? Not being
able to return a self ptr from initialize seems to stump me.

--Jonathan

···

--
Posted via http://www.ruby-forum.com/\.

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.

Hi,

How do you all think the term 'static class' fits?

Nope, just because it's not static at all.

How do you actually implement the singleton pattern in Ruby? Not being
able to return a self ptr from initialize seems to stump me.

Four ideas:

  * A plain object + singleton methods
  * A module with singleton methods
  * singleton library in the standard libraries
  * An ordinary class and pre-allocated object with convention not to
    create any other objects.

              matz.

···

In message "Re: injecting dynamic methods into a class" on Thu, 8 Dec 2005 11:22:02 +0900, "jonathan <zjll9@imail.etsu.edu>" <zjll9@imail.etsu.edu> writes:

Well the easy way is

require 'singleton'
class IWantToBeASingleton
      include Singleton
end

And the slighlty harder way

class IAlsoAmASingleton
        class << self
                private :new
         end
        def self.instance
               @inst ||= new
        end
end

···

On Dec 7, 2005, at 9:22 PM, jonathan <zjll9@imail.etsu.edu> wrote:

jonathan wrote:

transfire wrote:

'Ad hoc' has too many negative connotations and singleton has a fairly
unambiguous meaning.

I felt the same way at first, until I started using it, keeping in mind
the strict definition --even the Latin definition: *for this*.

That's really interesting. It's unfortunate that the most common use of
the term is a secondary meaning. I guess using it will motivate people
to find out primary meaning. I'm all for it. :slight_smile:

Just to clarify (I hadn't finished reading all the posts when I made the
above comment). I don't mean to make my vote 'for' this term, but, I
meant that I was for using a term in a way that educates. Most of us
are people that like to learn anyway. :slight_smile:

Having many terms for the same thing isn't necessarily a bad thing. It
happens in every other aspect of programming as well (class methods are
called 'member functions', 'methods', 'member methods', etc.).

How do you all think the term 'static class' fits?

Also, one more thing:

How do you actually implement the singleton pattern in Ruby? Not being
able to return a self ptr from initialize seems to stump me.

--Jonathan

--
Posted via http://www.ruby-forum.com/\.

Yes but we don't have Class#member, Class#method, Class#member_method,
Class#attribute, and Class#feature, etc. in Ruby. We have Class#method and
that all by itself probably forces a canonical term for the concept.

I would guess that if there was no programatic way in Ruby to
reference or manipulate a singleton class then there wouldn't be such
a buzz about coming up with a standard name for it.

We have Object#class and Class#superclass which emphasize, if
not define, the canonical names for these things in Ruby. There is no
similar standard method in Ruby that returns the object generated by
the expression:

  (class <<obj; self; end)

and since it is supremely awkward to type or say that expression to
refer to the concept, we all have our own habits in this regard and
only the social forces of the community to influence these habits.
I bet if you searched all the Ruby code ever written you would see
all sorts of things like:

  def vclass(obj)
    (class <<obj; self; end)
         end

where vclass might be: meta, singleton, sclass, virtclass, eclass, eigen,
aclass, adhoc, shadow, and so on. Everybody is coming up with their own
mnemonic for the concept because, well, you need a name if you are going
wrap up that expression in a method.

So all this is a long way of saying that what I really want for Christmas
is a short name for (class <<obj; self; end). But if I don't get that,
I'll still be very happy with getting Ruby 1.8.4, which I will brag about
to all my friends who are still stuck with their crufty old static language
tools. :slight_smile:

Gary Wright

···

On Dec 7, 2005, at 9:22 PM, jonathan wrote:

Having many terms for the same thing isn't necessarily a bad thing. It
happens in every other aspect of programming as well (class methods are
called 'member functions', 'methods', 'member methods', etc.).

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

···

On Wed, 7 Dec 2005, Trans wrote:
__
David A. Black
dblack@wobblini.net

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

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.

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.

···

In message "Re: injecting dynamic methods into a class" on Wed, 7 Dec 2005 03:07:34 +0900, "Trans" <transfire@gmail.com> writes:

matz wrote:

Hi,

>How do you all think the term 'static class' fits?

Nope, just because it's not static at all.

It seems to be a term that .NET (and I think C++) uses:

see <a
href="Microsoft Learn: Build skills that open doors in your career;

In what way would the class not be static in Ruby? In the sense that
you can still metaprogram (or is it more than that)?

I think the term static refers to the fact that the data is static (that
is, there isn't a new copy of the data members for each instance) and
that each method is static (doesn't change any data members). One could
argue that adding code to a class is dynamic, but it could be understood
that the term 'static' only refers to data.

I guess the term is not a *perfect* match. But, then again, none of the
ones suggested, except maybe 'eigenclass' is.

--Jonathan

···

In message "Re: injecting dynamic methods into a class" > on Thu, 8 Dec 2005 11:22:02 +0900, "jonathan <zjll9@imail.etsu.edu>" > <zjll9@imail.etsu.edu> writes:

--
Posted via http://www.ruby-forum.com/\.

logancapaldo wrote:

And the slighlty harder way

class IAlsoAmASingleton
        class << self
                private :new
         end
        def self.instance
               @inst ||= new
        end
end

Ahh. That makes sense.

Thanks!

···

--
Posted via http://www.ruby-forum.com/\.

Hi --

···

On Thu, 8 Dec 2005, gwtmp01@mac.com wrote:

So all this is a long way of saying that what I really want for Christmas
is a short name for (class <<obj; self; end). But if I don't get that,
I'll still be very happy with getting Ruby 1.8.4, which I will brag about
to all my friends who are still stuck with their crufty old static language
tools. :slight_smile:

I'm hoping my Kernel#singleton_class RCR will get approved in some
form once some of this is resolved. It's partly a question of whether
the implementation of per-object behavior is going to continue to be
as class-based as it is now.

David

--
David A. Black
dblack@wobblini.net

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

gwtmp01 wrote:

Having many terms for the same thing isn't necessarily a bad
thing. It
happens in every other aspect of programming as well (class methods
are
called 'member functions', 'methods', 'member methods', etc.).

Yes but we don't have Class#member, Class#method, Class#member_method,
Class#attribute, and Class#feature, etc. in Ruby. We have
Class#method and
that all by itself probably forces a canonical term for the concept.

Ahh. Ok. I think I also gathered from other posts that it also helps
to be able to differentiate these for the purpose of error messages.
Well, this may be a solution:

Let the type of singleton which implements the singleton design pattern
remain as a 'singleton' in error messaging and introspection. But, let
the class which is a singleton by having nothing but class methods be
known as a simpleton.

In essence, from the outside, they look the same (and please correct me
if I'm wrong because I don't know all the Ruby syntax yet, but in
essence I think they are the same). Simpleton and singleton are
synonyms as far as I know. And, these two ways of arriving at a
singleton produce the same effect for the consumer (but differentiating
them is nice for error messaging and introspection).

--Jonathan

···

On Dec 7, 2005, at 9:22 PM, jonathan wrote:

--
Posted via http://www.ruby-forum.com/\.

David A. Black wrote:

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.

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.

···

On Wed, 7 Dec 2005, Trans wrote:

Yukihiro Matsumoto wrote:

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.

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.

···

In message "Re: injecting dynamic methods into a class" > on Wed, 7 Dec 2005 03:07:34 +0900, "Trans" <transfire@gmail.com> writes: