injecting dynamic methods into a class

[Trans]

I wasn't really insulting him. Just putting it back on him, so to
speak. Its a common phrase when someones feeding you contradictory
rhetoric, so you respond like that.

Irregadless, I do have some issues with some of the things David said
in this thread. He essentially put words in my mouth and even implied
that I was belittling Matz. Which isn't the case and isn't a very nice
way to discuss the issue. Sometimes I think David deserves a little
gusto in his direction. I don't know if you've noticed but he often
gives me a hard time in particular, and he can get pretty thick with
the rhetoric when he does. So I wouldn't get too worked up if I get a
little brazen with him. David and I have been here plenty of times
before. Haven't we? Probably will again. Seems like we're kind of polar
opposites at times. Anyway, I've come to expect it. So it is what it
is. I don't begrudge David despite our differences. And I don't expect
he does me either --well, at least I hope he's not stewing at home over
"that lousy no good trans" or something.

And just a little reminder. It was I who called for "Three Cheers for
David". I do appreciate what he's done, very much so. That doesn't mean
I'm always going to kiss his ars ;-)

 

[daz]

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

But, IIUC, slaughter is frowned upon by civilised communities?

Quotes from:
http://use.perl.org/~Stevan/journal/27085
[ Saturday October 08, 2005 ]

"... shows how class-methods can be implemented using ruby-style
eigenclasses (or singleton-methods as they are also called)."


-- Well, well. We're always the last to know ;(


"Using the eigenclasses results in a very normalized method dispatch
mechanism where instance method and class method dispatch are exactly
the same. What else can I say about that but ruby++."


^ ^
@ @
|
{-}



daz

 

[Martin DeMello]

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.

Note that the language itself doesn't call it *anything*. Indeed, there
isn't even an accessor for it, short of opening up its scope and
returning 'self'. So this is not equivalent to, say, suddenly deciding
to call Hashes Dictionaries instead - indeed, it's more a jargon issue
than a ruby-the-language one. Sort of akin to <=> coming to be called
the spaceship operator, or #! the shebang line.

martin

 

[dblack]

Hi --

Note that the language itself doesn't call it *anything*. Indeed, there
isn't even an accessor for it, short of opening up its scope and
returning 'self'.

I think that might change, though (I hope), once a long-term decision
is reached about the name and for that matter the implementation (if
it changes).

So this is not equivalent to, say, suddenly deciding
to call Hashes Dictionaries instead - indeed, it's more a jargon issue
than a ruby-the-language one. Sort of akin to <=> coming to be called
the spaceship operator, or #! the shebang line.

Not quite:

ruby -ve 'class << 3; end'
ruby 1.9.0 (2005-05-20) [i686-linux]
-e:1: no singleton class for Fixnum (TypeError)

Also, with Matz discussing it so much, I'd put it in the category
of having official-name status.

But I know what you mean about jargon. Just as people call objects
"underlying thingies" and so forth, there's no particular reason for
people not to use a term like "own class" or "eigenclass" (or "class a
soi", if they want to translate it into yet another language
descriptively. It's just that the burgeoning usage and positioning of
some of these terms have been unfortunate, in relation to the process
already underway.


David

 

[MenTaLguY]

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

I don't think it's necessary to pigeon-hole Ruby philosophically.

I mainly intended to raise the question of whether bringing social
obligation into the discussion that way was really appropriate. It
tends to be poisonous in technical forums.

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.

There are two reasons for this: one, the name is one of the few aspects
of Ruby which people are fairly consistently unhappy with, and secondly,
it's an issue of human linguistics rather than of the programming
language.

I think we should expect an issue of human language to be resolved in
the fashion natural to it, rather than the more "up-front" and
centralized fashion typical for programming language issues.

(Of course, as noted elsewhere, I am a staunch linguistic descriptivist.
So perhaps that colors my thinking.)

=20
Right -- it's about what to call singleton classes, and I wish people
would discuss it and then let Matz decide.

I think that's what people are doing, basically. That discussion is
simply going to be accomplished a bit differently than it would be for a
feature of the programming language itself. The negotiation of new
human vocabulary involves trying alternatives in the real world and
seeing what sticks.

Based on Matz's most recent post, it sounds like that's what he's
waiting for too.

-mental

--=-HhlPgYISBWVieKjGZ049
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)

iD8DBQBDlvyAcUNIGiXCc4MRAvUBAKC1ptgZW5oYGbAytUwVRj3uBYo+AgCfWNnX
sEnj2FOoAVuOI1L/yiTnz+U=
=ohkc
-----END PGP SIGNATURE-----

--=-HhlPgYISBWVieKjGZ049--

 

[Ryan Leavengood]

Here we go again with the endless discussion threads. I guess most of
you know my feelings on these threads based on a post not too long
ago, but I can't help but be sucked into this one too.

Firstly, in general I agree with David that we are on a slippery slope
with everyone using their own favorite singleton class synonym. For
that matter I'll bring my own favorite, shadow class, back into the
fray and muddy the waters more. All these terms will definitely
confuse newcomers and possibly even old hats, and it is sort of
annoying having to "translate" all the time.

But at the same time, I'm not sure how else these terms can be tested
out without actually using them. It seems Matz is sort of just waiting
and seeing what happens, which isn't a bad philosophy, but can
certainly result in some impatience and certain people trying to
impose their own standards on other people.

So with that wishy-washy essay out of the way, let me conclude with
some advice for Trans: I'm not sure if you realize it, but at least
from my perspective (and I'm sure others), I see you as some kind of
Ruby traitor, trying to subvert it from within. I would say "rebel",
but I don't think that conveys enough negativity. Every week it seems
like there is some thread spawned by you discussing the merits of some
massive change to Ruby. While in general this may not be a bad thing,
with the frequency I see it I can't help but automatically dismiss
much of what you say. Even a lot of the good work you have done on
Facets or Nano or Mega or Calibre or whatever it is called can be
dismissed because of the name changes and disorganization I've just
indicated. As harsh as this paragraph is, I don't mean it as a "screw
you Trans" type of thing, just an indication that is how at least one
person percieves you, and for most people, perception is reality.

Ryan

 

[Trans]

A Ruby TRAITOR? Because I offer up opinions, options and interesting
new ideas that arn't status quo?

Ah forget it. It aint worth it any more. You win Ryan. I repent.

Adhoc
Module method inheritance
Core versioning support
AOP Cuts
Using core for tech discussions
Perfecting the organization of Facets/Calibre
Yes, the list goes on....

But all terrible terrible things! How evil I am for even mentioning
them, let alone actually trying to do them. Ugh, what a turncoat I have
been, an enemy of the Ruby state! Down witht he evil trans. Kill him.
KILL HIM!!!

 

[Ryan Leavengood]

ROFL. OK maybe traitor was a bit too dramatic. But this response was
worth it.

Let's just try to find the middle ground between generally useful Ruby
changes and changes just because someone thinks they are cool.

Just so you know since I've been so "anti-Trans" in the past I plan to
look over Calibre and write about some of the gems (pun-intended) in
there.

Ryan

 

[Robert Klemme]

Firstly, in general I agree with David that we are on a slippery slope
with everyone using their own favorite singleton class synonym. For
that matter I'll bring my own favorite, shadow class, back into the
fray and muddy the waters more. All these terms will definitely
confuse newcomers and possibly even old hats, and it is sort of
annoying having to "translate" all the time.

You just made a case for sticking to "singleton class". ) I for my part
stick with the old fashioned but well established term. My 0.02EUR...

Kind regards

robert

 

[dblack]

Hi --

I think that's what people are doing, basically. That discussion is
simply going to be accomplished a bit differently than it would be for a
feature of the programming language itself. The negotiation of new
human vocabulary involves trying alternatives in the real world and
seeing what sticks.

Can't we just look at this as what it is, instead of finding a huge,
trans-historical thing that tells us what it "should" be? Let's just
let Matz decide. Sorry to be so pedestrian

Based on Matz's most recent post, it sounds like that's what he's
waiting for too.

I interpreted it differently; he said, as I read it, that he's
sticking with singleton class for now. But as I've said, this is a
done deal: people are going to use a bunch of different terms, no
matter who says what at this point.


David

 

[dblack]

Hi --

But, IIUC, slaughter is frowned upon by civilised communities?

"[Ruby], red in tooth and claw"


David

 

[Martin DeMello]

On Wed, 7 Dec 2005, Martin DeMello wrote:

Not quite:

ruby -ve 'class << 3; end'
ruby 1.9.0 (2005-05-20) [i686-linux]
-e:1: no singleton class for Fixnum (TypeError)

A very palpable hit

Also, with Matz discussing it so much, I'd put it in the category
of having official-name status.

But I know what you mean about jargon. Just as people call objects
"underlying thingies" and so forth, there's no particular reason for
people not to use a term like "own class" or "eigenclass" (or "class a
soi", if they want to translate it into yet another language
descriptively. It's just that the burgeoning usage and positioning of
some of these terms have been unfortunate, in relation to the process
already underway.

But IMO this is the only real way to make sure that, when we do
standardise on a term, it's a good one.

martin

 

[dblack]

Hi --

On Wed, 7 Dec 2005, Martin DeMello wrote:

Not quite:

ruby -ve 'class << 3; end'
ruby 1.9.0 (2005-05-20) [i686-linux]
-e:1: no singleton class for Fixnum (TypeError)

A very palpable hit

Also, with Matz discussing it so much, I'd put it in the category
of having official-name status.

But I know what you mean about jargon. Just as people call objects
"underlying thingies" and so forth, there's no particular reason for
people not to use a term like "own class" or "eigenclass" (or "class a
soi", if they want to translate it into yet another language
descriptively. It's just that the burgeoning usage and positioning of
some of these terms have been unfortunate, in relation to the process
already underway.

But IMO this is the only real way to make sure that, when we do
standardise on a term, it's a good one.

Or at least a frequently-used one I know it's possible to discuss
something to death, and it's possible that this has happened with
singleton-class renaming already. But consider that someone just
coming across a reference to "Ruby's eigenclasses" (or whatever) isn't
even going to know that there's any history, discussion, uncertainty
-- basically, isn't going to know that there's any reason to think
about whether the term is or is not a good one. They'll just accept
the term and start propagating it -- which, therefore, doesn't count
as a "vote", so to speak.

Also, the standard that's really emerging is the standard practice of
calling singleton classes by many different names. Maybe we should
just embrace this. It might lead to more publicity than choosing one
name


David

 

[jonathan]

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.

 

[jonathan]

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.

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.

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

 

[Yukihiro Matsumoto]

Hi,

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

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

 

[Logan Capaldo]

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.

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

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

 

[Trans]

Just so you know since I've been so "anti-Trans" in the past I plan to

look over Calibre and write about some of the gems (pun-intended) in
there.

Hey, thanks. That would be great! I hope you find some the "gems"
useful.

T.

 

[Trans]

Just so you know since I've been so "anti-Trans" in the past I plan to

look over Calibre and write about some of the gems (pun-intended) in
there.

Cool thanks. I hope you find a "gem" of use to you.

T.

 

[jonathan]

Hi,

In message "Re: injecting dynamic methods into a class"
on Thu, 8 Dec 2005 11:22:02 +0900, "jonathan <[email protected]>"

|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="http://msdn2.microsoft.com/en-us/library/79b3xss3.aspx">http://msdn2.microsoft.com/en-us/library/79b3xss3.aspx</a>

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