Oops, meant to say 'doesn't change any non-static (or non-class-wide, or
instance-specific)' members.
--Jonathan
jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu. wrote:
that each method is static (doesn't change any data members). One could
--
Posted via http://www.ruby-forum.com/\.
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;
I thought we were talking about so called singleton classes, right?
It's totally different from static classes in C# and C++.
Singleton classes in Ruby are:
* created run time on demand
* can be modified (or enhanced) run time
* their methods may modify any instances
* their scope are not limited to certain file
matz.
In message "Re: injecting dynamic methods into a class" on Thu, 8 Dec 2005 11:45:18 +0900, "jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu>" <zjll9@imail.etsu.edu> writes:
Hi --
On Thu, 8 Dec 2005, jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> wrote:
gwtmp01 wrote:
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.).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.
Do you know what the word "simpleton" means? It's really not a
candidate for a name for a language construct.
Anyway -- I'm trying to follow along but not sure what you mean by
classes that have nothing but class methods and class data. Can you
give a code example of such a class?
David
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Hi --
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.
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
On Wed, 7 Dec 2005, Trans wrote:
> On Wed, 7 Dec 2005, Trans wrote:
__
David A. Black
dblack@wobblini.net
"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Trans wrote:
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
Ruby Code & Style - 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
matz wrote:
I thought we were talking about so called singleton classes, right?
It's totally different from static classes in C# and C++.
Well, I thought we were talking about classes which contain only class
methods and class data (which are currently called 'singletons'). But,
in C# or C++ these are called 'static classes.' I guess that makes
sense for them because the code itself can never change or be enhanced
(like it can be in Ruby).
Singleton classes in Ruby are:
* created run time on demand
* can be modified (or enhanced) run time
* their methods may modify any instances
* their scope are not limited to certain filematz.
Ok. That's what I meant by metaprogramming. I wasn't aware of the
scope issue though. Also, what do you mean by 'their methods may modify
any instances'?
But, yea, given the 'dynamic' nature of Ruby, it doesn't make sense to
say something is static.
--Jonathan
--
Posted via http://www.ruby-forum.com/\.
dblack wrote:
Anyway -- I'm trying to follow along but not sure what you mean by
classes that have nothing but class methods and class data. Can you
give a code example of such a class?
Here's a very simple example (a global counter):
<code>
class SingletonCounter
private_class_method :new
attr_accessor :count
@@counter = nil # class var which pts to instance
def initialize( count )
@count = count
end
def SingletonCounter.create
@@counter = new( 0 ) unless @@counter
@@counter
end
def increment( inc_amt )
@count += inc_amt
return @count
end
end
class Counter
@@count = 0 # class variable
def Counter.increment( inc_amt ) # class method
@@count = @@count + inc_amt
return @@count
end
end
sc = SingletonCounter.create
print sc.increment( 9 )
print sc.increment( 4 )
sc2 = SingletonCounter.create
print sc2.increment( 3 ) # points to same underlying obj as sc
c = Counter.new
print Counter.increment( 9 ) # in C#, you could do c.increment( 9 )
here
print Counter.increment( 4 )
c2 = Counter.new
print Counter.increment( 3 )
</code>
The first class is a true singleton and the second class is what is *in
essence* a singleton, but known as a static class in C#. One thing that
C# will let you do that makes this more transparent is
instancevar.staticmethod(). That apparently isn't the case in Ruby, so
that makes them less equivalent. (I suspected there would end up being
some syntax difference between the two, but the point I was making was
that they were the same in concept).
I don't know if any of this is really relevant, but hopefully you
understand statics, singletons, and C# a little better now. 
BTW,
this discussion is continued in another thread called 'About class
methods'.
--J
--
Posted via http://www.ruby-forum.com/\.
dblack wrote:
>
> 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.Do you know what the word "simpleton" means? It's really not a
candidate for a name for a language construct.Anyway -- I'm trying to follow along but not sure what you mean by
classes that have nothing but class methods and class data. Can you
give a code example of such a class?
Please Ignore.
[**1] Top 15 Trang Cá Cược, Cá Độ Bóng Đá Uy Tín Nhất Việt Nam
On Thu, 8 Dec 2005, jonathan <T.SockPuppet[**1]> wrote:
David A. Black wrote:
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 
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
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
On Dec 6, 2005, at 2:42 PM, David A. Black wrote:
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.
I don't know, man. Personally at this point I think we should stand
back and let natural selection do its thing.
-mental
On Wed, 2005-12-07 at 04:42 +0900, David A. Black wrote:
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 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 
MenTaLguY wrote:
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
Hi,
In message "Re: injecting dynamic methods into a class" on Thu, 8 Dec 2005 15:39:06 +0900, "jonathan <zjll9@imail.etsu.edu>" <zjll9@imail.etsu.edu> writes:
Singleton classes in Ruby are:
* created run time on demand
* can be modified (or enhanced) run time
* their methods may modify any instances
* their scope are not limited to certain filematz.
Ok. That's what I meant by metaprogramming. I wasn't aware of the
scope issue though. Also, what do you mean by 'their methods may modify
any instances'?
Nevermind. I was confusing const and static. Silly.
matz.
Hi --
dblack wrote:
Anyway -- I'm trying to follow along but not sure what you mean by
classes that have nothing but class methods and class data. Can you
give a code example of such a class?Here's a very simple example (a global counter):
<code>
class SingletonCounter
private_class_method :new
attr_accessor :count
@@counter = nil # class var which pts to instance
def initialize( count )
@count = count
end
def SingletonCounter.create
@@counter = new( 0 ) unless @@counter
@@counter
end
def increment( inc_amt )
@count += inc_amt
return @count
end
endclass Counter
@@count = 0 # class variable
def Counter.increment( inc_amt ) # class method
@@count = @@count + inc_amt
return @@count
end
endsc = SingletonCounter.create
print sc.increment( 9 )
print sc.increment( 4 )sc2 = SingletonCounter.create
print sc2.increment( 3 ) # points to same underlying obj as scc = Counter.new
print Counter.increment( 9 ) # in C#, you could do c.increment( 9 )
here
print Counter.increment( 4 )c2 = Counter.new
print Counter.increment( 3 )</code>
The first class is a true singleton and the second class is what is *in
essence* a singleton, but known as a static class in C#.
In Ruby it's just known as a class I'd highly recommend not
trying to shoehorn the term "static" into Ruby. It's never going to
be a good fit.
(Don't neglect the Singleton module, by the way, which will do the
singleton-ing for you.)
There's nothing at the language level that stops you from adding an
instance method to Counter. You can give a name to a style of coding
where you don't write instance methods, but it's definitely not a
language feature.
David
On Sat, 10 Dec 2005, jonathan <zjll9@imail.etsu.edu> <zjll9@imail.etsu.edu> wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Hi --
> 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.
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
On Wed, 7 Dec 2005, MenTaLguY wrote:
On Wed, 2005-12-07 at 04:42 +0900, David A. Black wrote:
__
David A. Black
dblack@wobblini.net
"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Hi --
On Wed, 7 Dec 2005, daz wrote:
MenTaLguY wrote:
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?
"[Ruby], red in tooth and claw"
David
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", forthcoming from Manning Publications, April 2006!
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
On Wed, 2005-12-07 at 06:32 +0900, David A. Black wrote:
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
David A. Black <dblack@wobblini.net> wrote:
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.
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
On Wed, 2005-12-07 at 11:18 +0900, MenTaLguY wrote:
People were free to do their own thing, and yet the project
leaders were more respected.