[RCR] Object#inside_metaclass?
Ara.T.Howard
this is very useful for meta-programming:
jib:~/eg/ruby > cat a.rb
class Object
def inside_metaclass?
klass = Class === self ? self : self.class
obj_meta = class << Object; self; end
klass.ancestors.include? obj_meta
end
end
p inside_metaclass?
class << self
p inside_metaclass?
end
class C
p inside_metaclass?
class << self
p inside_metaclass?
class << self
p inside_metaclass?
end
end
end
jib:~/eg/ruby > ruby a.rb
false
true
false
true
true
i believe the implementaion is correct iff the following statement is true:
all meta-classes descend from the meta-class of Object.
-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| renunciation is not getting rid of the things of this world, but accepting
| that they pass away. --aitken roshi
===============================================================================
Ilias Lazaridis
>
> this is very useful for meta-programming:
>
> jib:~/eg/ruby > cat a.rb
> class Object
> def inside_metaclass?
> i believe the implementaion is correct iff the following statement is true:
>
> all meta-classes descend from the meta-class of Object.
the statement is false.
The Ruby Language, in it's current implementation, has no MetaClasses:
http://lazaridis.com/case/lang/ruby/index.html
-
Please avoid this amateurish re-definition of terminology.
.
Martin DeMello
>
>
> i believe the implementaion is correct iff the following statement is true:
>
> all meta-classes descend from the meta-class of Object.
That's a very neat approach. Much more satisfying than string-scraping.
martin
David A. Black
>
> this is very useful for meta-programming:
>
> jib:~/eg/ruby > cat a.rb
> class Object
> def inside_metaclass?
> klass = Class === self ? self : self.class
> obj_meta = class << Object; self; end
> klass.ancestors.include? obj_meta
> end
> end
>
> p inside_metaclass?
>
> i believe the implementaion is correct iff the following statement is true:
>
> all meta-classes descend from the meta-class of Object.
I fear the terminology issue raises its head here. Is there any
reason not to use the customary "singleton class", pending some
pronouncement from Matz that it's no longer the right term?
David
--
David A. Black
dbl...@wobblini.net
Ilias Lazaridis
> On Wed, 4 May 2005, Ara.T.Howard wrote:
>> all meta-classes descend from the meta-class of Object.
>
> I fear the terminology issue raises its head here. Is there any
> reason not to use the customary "singleton class",
"singleton class" has already a meaning within OOP.
like this: "a class which has only one instance"
> pending some
> pronouncement from Matz that it's no longer the right term?
You don't need a pronouncement from the language-designer.
The community should ensure a quick adoption of the Ruby Language.
concise terminology, which does not ignore the status-quo, is an
essential part of this.
http://lazaridis.com/case/lang/ruby/index.html
.
Jim Weirich
David A. Black said:
>> i believe the implementaion is correct iff the following statement is
>> true:
>>
>> all meta-classes descend from the meta-class of Object.
>
> I fear the terminology issue raises its head here. Is there any
> reason not to use the customary "singleton class", pending some
> pronouncement from Matz that it's no longer the right term?
There is a distinction, although some people blur it. Those things that
are almost metaclasses (but aren't because Ruby doesn't have metaclasses)
are a subset of all singleton classes. As noted, these almost-metaclasses
inherit from the almost-metaclass of Object. These almost-metaclasses are
the singleton classes of Class objects.
All almost-metaclasses are singleton classes. Not all singleton classes
are almost-metaclasses.
--
-- Jim Weirich j...@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
David A. Black
On Thu, 5 May 2005, Jim Weirich wrote:
>
> David A. Black said:
>>> i believe the implementaion is correct iff the following statement is
>>> true:
>>>
>>> all meta-classes descend from the meta-class of Object.
>>
>> I fear the terminology issue raises its head here. Is there any
>> reason not to use the customary "singleton class", pending some
>> pronouncement from Matz that it's no longer the right term?
>
> There is a distinction, although some people blur it.
That's what I mean (in case it wasn't clear): the two terms are not
synonymous, and we're seeing more and more of this blurring, and more
and more use of "metaclass" where Matz and most practitioners have
always said "singleton class". I'm hoping we can steer away from
this.
Mark Hubbart
>
> David A. Black said:
> >> i believe the implementaion is correct iff the following statement is
> >> true:
> >>
> >> all meta-classes descend from the meta-class of Object.
> >
> > I fear the terminology issue raises its head here. Is there any
> > reason not to use the customary "singleton class", pending some
> > pronouncement from Matz that it's no longer the right term?
>
> There is a distinction, although some people blur it. Those things that
> are almost metaclasses (but aren't because Ruby doesn't have metaclasses)
> are a subset of all singleton classes. As noted, these almost-metaclasses
> inherit from the almost-metaclass of Object. These almost-metaclasses are
> the singleton classes of Class objects.
>
> All almost-metaclasses are singleton classes. Not all singleton classes
> are almost-metaclasses.
All the more reason to give them a different name... At this point, I
care very little what they're called; virtual class, idioclass, own
class, whatever. Just give us a nice, non-overlapping name to call
them by. I guess singleton class will have to do until then, though...
With all these different names being thrown around, it feels like an
election year again! :)
cheers,
Mark
David A. Black
Actually one would not want a completely separate name, for the reason
that the almost-metaclasses really are singleton classes. Anything
generated by:
class << self; self; end
is a singleton class. If 'self' is a Class object, then the resulting
singleton class is also an almost-metaclass (parametaclass?!). But it
doesn't cease to be a singleton class.
Jim Weirich
Then I wasn't clear either. In answer to your question 'Is there any
reason not to use the customary "singleton class"', the answer is "Yes,
because the original posters statement becomes false if you substitute
singleton class for metaclass".
(1) The statement "all singleton classes descend from the singleton class
of Object" is false.
(2) The statement "all metaclasses descend from the metaclass of Object"
is true
(given that that in this context metaclass refers to those things that are
almost-metaclasses, i.e. singleton classes of classes.[1]).
There is a difference in meaning between the word singleton class and
metaclass. The original poster was using the correct terminology and
substituting the term "singleton class" would be incorrect.
--
-- Jim Weirich j...@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
[1] I'm trying to sidestep the issue of whether these almost-metaclasses
are TRUE metaclasses. They certainly are very much like metaclasses[2].
[2] Pickaxe II, page 382. "Eventually, Matz weighed in with the
following: [...] * Singleton classes for classes behave just like
Smalltalk's metaclasses"
Ara.T....@noaa.gov
the only problem is that is doesn't work !! ;-(
i had another definition in scope in irb when i tested - so sorry.
i'm back to this now, it's the best i can manange attm:
class Class
def inside_metaclass?
inspect =~ %r/^#<Class:/ ? true : false
end
end
class Object
def inside_metaclass?
self.class.inside_metaclass?
end
end
;-(
i'm waiting for the french to come to the rescue.
Christoph
>
>(1) The statement "all singleton classes descend from the singleton class
>of Object" is false.
>
>(2) The statement "all metaclasses descend from the metaclass of Object"
>is true
>
>
Nope - the singleton class of Module is not a meta_class but it
descends from the
singleton class of Object.
/Christoph
Christoph
That is plain false (at least in my understanding of what
you are trying
class << Module
>
> -a
Christoph
>
> class Class
> def inside_metaclass?
> inspect =~ %r/^#<Class:/ ? true : false
> end
> end
>
> class Object
> def inside_metaclass?
> self.class.inside_metaclass?
> end
> end
I see - thats what you call a meta class - actually you
statement seems to be right, just the ancestors implementation
in 1.8 seems to have a bug - try
---
def inside_metaclass?
false
end
class << Object
private
def inside_metaclass?
true
end
end
---
/Christoph
Florian Groß
> this is very useful for meta-programming:
>
> jib:~/eg/ruby > cat a.rb
> class Object
> def inside_metaclass?
Why? Any real world samples?
Jim Weirich
Module is a class (instances of Module are modules). The singleton class
of module would be a metaclass[1] (a class of a class ... since Module is
a class).
--
-- Jim Weirich j...@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
[1] or quasi-proto-faux-metaclass if you prefer.
Ara.T....@noaa.gov
hmm - seems like something like that could work alright... but this fails:
jib:~/eg/ruby > cat a.rb
def inside_metaclass?
false
end
class << Object
private
def inside_metaclass?
true
end
end
p inside_metaclass?
class << self
p inside_metaclass?
end
class C
p inside_metaclass?
end
jib:~/eg/ruby > ruby a.rb
false
true
true
it's not easy...
Ara.T....@noaa.gov
class C
class << self
trait 'a' => 'default_value'
end
trait 'a' => 'default_value'
end
the first case is defining a trait (attr) with a default value at the class
scope. obviously the default value can be set immediately. in the second
case we are defining an instance method with a default value. this value
obviously cannot be set now so, instead, the code generated does a lazy lookup
of the default value when the value is read the first time. the defaults are
stored in the class as a class instance variable. it's sort hard to show in a
little code but __logically__ we end up with something like (greatly simplified)
class C
@trait_defaults = {
'class' => { 'a' => 'default_value' },
'instance' => { 'a' => 'default_value' },
}
def C::a
@a = @trait_defaults['class']['a'] unless defined? @a
@a
end
def a
@a = @trait_defaults['instance']['a'] unless defined? @a
@a
end
end
so i need to know, at the point of definition if we're inside a metaclass to
generate the code slightly differently. all the above is for explanation only
and is nothing like real code.
cheers.
David A. Black
On Thu, 5 May 2005, Jim Weirich wrote:
>
> David A. Black said:
>>
>> That's what I mean (in case it wasn't clear): the two terms are not
>> synonymous, and we're seeing more and more of this blurring, and more
>> and more use of "metaclass" where Matz and most practitioners have
>> always said "singleton class". I'm hoping we can steer away from
>> this.
>
> Then I wasn't clear either. In answer to your question 'Is there any
> reason not to use the customary "singleton class"', the answer is "Yes,
> because the original posters statement becomes false if you substitute
> singleton class for metaclass".
>
> (1) The statement "all singleton classes descend from the singleton class
> of Object" is false.
>
> (2) The statement "all metaclasses descend from the metaclass of Object"
> is true
>
> (given that that in this context metaclass refers to those things that are
> almost-metaclasses, i.e. singleton classes of classes.[1]).
>
> There is a difference in meaning between the word singleton class and
> metaclass. The original poster was using the correct terminology and
> substituting the term "singleton class" would be incorrect.
I disagree; I think Ara was using the term "metaclass" to mean
"singleton class". I'm taking my cue from his sample code:
# (top level code)
p inside_metaclass? # false
class << self
p inside_metaclass? # true
end
So his concept of "inside a metaclass" includes "inside a non-class
object's singleton class" (since top-level self is not a class).
He then predicates that his code only works iff "all metaclasses
descend from the metaclass of Object", but if he's using
"metaclass" to mean the same thing he meant it to mean in
"inside_metaclass?", then this means singleton class (and the
statement is false).
(I'm working in the dark a little here as the examples all print
'false' for me in 1.8.2 and slightly old 1.9. I guess Ara's using a
recent 1.9 -- ?)
David A. Black
> it's sort hard to show in a little code but __logically__ we end up
> with something like (greatly simplified)
>
> class C
>
> @trait_defaults = {
> 'class' => { 'a' => 'default_value' },
> 'instance' => { 'a' => 'default_value' },
> }
>
> def C::a
(Just out of curiosity: do you mean to depart from the usual C.a here?
And why? :-)
> @a = @trait_defaults['class']['a'] unless defined? @a
> @a
> end
>
> def a
> @a = @trait_defaults['instance']['a'] unless defined? @a
> @a
> end
> end
>
> so i need to know, at the point of definition if we're inside a
> metaclass to generate the code slightly differently. all the above
> is for explanation only and is nothing like real code.
I understand the not real code point, but still, it's showing
something I can't quite follow, namely the @trait_defaults instance
variable in the instance method definition (def a). Do you mean this
to refer to the class's instance variable?
I'm also not sure where inside_metaclass? would go here. Can you
rewrite it into pseudo-code looking how it would look if that method
existed?
Ara.T....@noaa.gov
>> There is a difference in meaning between the word singleton class and
>> metaclass. The original poster was using the correct terminology and
>> substituting the term "singleton class" would be incorrect.
>
> I disagree; I think Ara was using the term "metaclass" to mean "singleton
> class". I'm taking my cue from his sample code:
>
> # (top level code)
>
> p inside_metaclass? # false
>
> class << self
> p inside_metaclass? # true
> end
>
> So his concept of "inside a metaclass" includes "inside a non-class object's
> singleton class" (since top-level self is not a class).
it does - but inadvertently. the only requirement i have is to determine
'inside_metaclass?' as in
class C
class << self
p inside_metaclass? # true
end
end
the singleton meaning accreted itself into my impl in a moment of stupidity
;-(
> He then predicates that his code only works iff "all metaclasses descend
> from the metaclass of Object", but if he's using "metaclass" to mean the
> same thing he meant it to mean in "inside_metaclass?", then this means
> singleton class (and the statement is false).
you are right. i didn't mean it - honest! my need to is to have context
sensitive class methods
class C
method # does something
class << self
method # does another thing
end
end
and that's all.
> (I'm working in the dark a little here as the examples all print 'false' for
> me in 1.8.2 and slightly old 1.9. I guess Ara's using a recent 1.9 -- ?)
hmm. here's mine:
jib:~/eg/ruby > cat a.rb
class Class
def inside_metaclass?
inspect =~ %r/^#<Class:/ ? true : false
end
end
class << self
p inside_metaclass?
end
class C
p inside_metaclass?
class << self
p inside_metaclass?
class << self
p inside_metaclass?
end
end
end
jib:~/eg/ruby > ruby a.rb
true
false
true
true
but this has been pointed out to break for anonymous classes. arggh.
David A. Black
On Thu, 5 May 2005 Ara.T....@noaa.gov wrote:
> I wrote:
>>
>> So his concept of "inside a metaclass" includes "inside a non-class
>> object's
>> singleton class" (since top-level self is not a class).
>
> it does - but inadvertently. the only requirement i have is to determine
> 'inside_metaclass?' as in
>
> class C
> class << self
> p inside_metaclass? # true
> end
> end
>
> the singleton meaning accreted itself into my impl in a moment of stupidity
> ;-(
>
>> He then predicates that his code only works iff "all metaclasses descend
>> from the metaclass of Object", but if he's using "metaclass" to mean the
>> same thing he meant it to mean in "inside_metaclass?", then this means
>> singleton class (and the statement is false).
>
> you are right. i didn't mean it - honest! my need to is to have context
> sensitive class methods
I believe you! :-) I just extrapolated from that one example and got
us sidetracked.
Ara.T....@noaa.gov
> Hi --
>
>> it's sort hard to show in a little code but __logically__ we end up
>> with something like (greatly simplified)
>>
>> class C
>>
>> @trait_defaults = {
>> 'class' => { 'a' => 'default_value' },
>> 'instance' => { 'a' => 'default_value' },
>> }
>>
>> def C::a
>
> (Just out of curiosity: do you mean to depart from the usual C.a here?
> And why? :-)
i've got a couple of coding conventions i use including:
- collections are plural
- class methods get called with ::
they help me know things like
p configs #=> this is an array of configs
x::send('method', *args) #=> x is a class
they are just habbits.
>
>> @a = @trait_defaults['class']['a'] unless defined? @a
>> @a
>> end
>>
>> def a
>> @a = @trait_defaults['instance']['a'] unless defined? @a
>> @a
>> end
>> end
>>
>> so i need to know, at the point of definition if we're inside a
>> metaclass to generate the code slightly differently. all the above
>> is for explanation only and is nothing like real code.
>
> I understand the not real code point, but still, it's showing something I
> can't quite follow, namely the @trait_defaults instance variable in the
> instance method definition (def a). Do you mean this to refer to the
> class's instance variable?
yes - sorry. both class methods AND instance methods must look up there
respective defaults in a class instance var.
you can read the real code at
http://codeforpeople.com/lib/ruby/traits/traits-0.0.0/
> I'm also not sure where inside_metaclass? would go here. Can you rewrite it
> into pseudo-code looking how it would look if that method existed?
class Class
def trait(*args)
if inside_metaclass?
define_class_traits(*args)
else
define_instance_traits(*args)
end
end
def class_trait(*args)
class << self
trait(*args)
end
end
end
make sense? obviously this would be easy if traits were like 'attr' and just
eval'd some code - but the defaults thing makes it hard since the defaults
must be stored somewhere in the case of instance traits and looked up later -
therefore the method definition of the trait itself must dynamically differ.
this is unlike attr_ methods. another reason for inside_metaclass? is that
traits works like
jib:~ > cat a.rb
require 'traits'
class C
class_trait 'a' => 42
class << self
trait 'b' => 'forty-two'
end
trait 'a' => 42.0
end
p C::reader_traits
p C::class_reader_traits
jib:~ > ruby a.rb
["a"]
["a", "b"]
now, 'reader_traits' and 'class_reader_traits' are also implemented like
def reader_traits(*args)
...
end
def class_reader_traits(*args)
class << self
reader_traits(*args)
end
end
eg. the __return__ value of reader_traits is context sensitive to being in/out
of a metaclass.
reason three:
jib:~ > cat a.rb
class C
p ancestors
class << self
p ancestors
end
end
jib:~ > ruby a.rb
[C, Object, Kernel]
[Class, Module, Object, Kernel]
now imagine you want to implement 'inheritence' for traits that use class @vars
(not @@vars) for default values (for the obvious reason). you need to look up
the chain of ancestors to find you defaults. problem: your ancestors vary
according to scope. i solve this by
klass =
if inside_metaclass?
pop_up_to_instance_klass
else
self
end
klass.ancestors.each{|a| look_for_default a }
the problem all boils down to this : attr_ and friends work exactly the same
whether called at a class or metaclass level. adding features like having
default values, inheritence of stuff, etc. makes the distinction of where you
are (class or metaclass) suddenly very important.
i hope i'm making myself clear now - i never meant for this to end up like
this! ;-)
Carlos
> hmm - seems like something like that could work alright... but this fails:
> it's not easy...
If you don't need to distinguish between singleton classes for classes and
normal objects, what's the problem with
def inside?
self.is_a?(Class) &&
self.name.empty?
self.ancestors.first != self
end
?
Ilias Lazaridis
> Hi -- On Thu, 5 May 2005, Mark Hubbart wrote:
>> All the more reason to give them a different name... At this point,
>> I care very little what they're called; virtual class, idioclass,
>> own class, whatever. Just give us a nice, non-overlapping name to
>> call them by. I guess singleton class will have to do until then,
>> though...
>
> Actually one would not want a completely separate name, for the
> reason that the almost-metaclasses really are singleton classes.
> Anything generated by:
>
> class << self; self; end
>
> is a singleton class.
no, it is not.
anything generated by (class << self; self; end)
has not _any_ instance.
Thus it is not a singleton class (which has _one_ instance)
-
It is a hidden class, a virtual class, or simply an "x-class".
x stands for "anything" / "mystery".
x stands for "exclusive" (to _one_ object)
object.xclass.
"singleton class" => x class
http://lazaridis.com/case/lang/ruby/index.html
> If 'self' is a Class object, then the
> resulting singleton class is also an almost-metaclass
> (parametaclass?!). But it doesn't cease to be a singleton class.
almost-metaclasses => meta-objects
or
xclass of class-obj
-
The first step to "break" out of the confusion is to release to term
"singleton-class", which has a specific meaning.
.
Ara.T....@noaa.gov
ha! first i noticed you made a typo (the first two lines are a no-op without
another '&&') - and then i ran it anyhow. funny thing is it seems the last
line is all that's needed (if defined in Class)!
jib:~/eg/ruby > cat a.rb
class Class
def inside_metaclass?
self.ancestors.first != self
end
end
class << self
p inside_metaclass? # true
end
class C
p inside_metaclass? # false
class << self
p inside_metaclass? # true
class << self
p inside_metaclass? # true
end
end
end
p Class::new.inside_metaclass? # false
class << Class::new
p inside_metaclass? # true
end
p self.class.inside_metaclass? # false
class << self
p inside_metaclass? # true
end
jib:~/eg/ruby > ruby a.rb
true
false
true
true
false
true
false
true
not bad! why do you suppose metaclasses don't have themselves as ancestors?
or perhaps put a better way - why DO normal classes?
this is great!
(please - somebody show me that it's wrong before i run wild with it ;-) )
kind regards.
Joel VanderWerf
> not bad! why do you suppose metaclasses don't have themselves as
> ancestors?
> or perhaps put a better way - why DO normal classes?
Mebbe because #ancestors shows the path that method lookup will follow,
_after_ checking for a singleton method.
irb(main):001:0> class << String; p ancestors; end
[Class, Module, Object, Kernel]
=> nil
There's no need to list the "metaclass" of String in the above, because
method lookup always starts with that object, if it exists, in case a
singleton method has been defined.
irb(main):002:0> class String; p ancestors; end
[String, Enumerable, Comparable, Object, Kernel]
=> nil
In this case, method lookup starts with the singleton class of the given
string (if one has been created), and then looks in the instance methods
of String, Enumerable, etc.
David A. Black
On Thu, 5 May 2005 Ara.T....@noaa.gov wrote:
> jib:~/eg/ruby > cat a.rb
> class Class
> def inside_metaclass?
> self.ancestors.first != self
> end
> end
>
> class << self
> p inside_metaclass? # true
> end
Isn't that the case we talked about before where you clarified that
you didn't think it should be 'true' for singleton classes in general?
If not, them I'm retroactively confused again about the whole thread
and the use of terminology.
Ara.T....@noaa.gov
makes sense. bad name then. should be Class#search_path or someting...
cheers.
Ara.T....@noaa.gov
lol. i've never heard of anyone being retroactively confused - but i'm sure i
am all the time. i think. maybe. i'm not sure.
anyways... this is the right __behaviour__ if not the right name. i'll change
it to inside_singleton? or something in my source.
too bad you can't edit usenet - anyone would think/know i'm a complete dolt if
reading this thread!
Carlos
> >def inside?
> > self.is_a?(Class) &&
> > self.name.empty?
> > self.ancestors.first != self
> >end
>
> ha! first i noticed you made a typo (the first two lines are a no-op
> without
> another '&&') - and then i ran it anyhow. funny thing is it seems the last
> line is all that's needed (if defined in Class)!
Yes, the #name thing was a leftover of some experiments trying to
distinguish between singleton classes of classes and the others
(unsuccessful). (This version was already in [ruby-talk:140408]...)
> not bad! why do you suppose metaclasses don't have themselves as ancestors?
> or perhaps put a better way - why DO normal classes?
I think Joel VanderWerf's explanation is the most likely.
David A. Black
On Thu, 5 May 2005 Ara.T....@noaa.gov wrote:
> On Thu, 5 May 2005, David A. Black wrote:
>
>> Isn't that the case we talked about before where you clarified that
>> you didn't think it should be 'true' for singleton classes in general?
>> If not, them I'm retroactively confused again about the whole thread
>> and the use of terminology.
>
> lol. i've never heard of anyone being retroactively confused - but i'm sure
> i
> am all the time. i think. maybe. i'm not sure.
>
> anyways... this is the right __behaviour__ if not the right name. i'll
> change
> it to inside_singleton? or something in my source.
>
> too bad you can't edit usenet - anyone would think/know i'm a complete dolt
> if
> reading this thread!
Well, I think I may be the dolt, since I always seem to be present
when these misunderstandings come up (me and Jim, me and you...) :-)
But in fact I think it does come back to the terminology problem.
inside_singleton? is a little unclear, and inside_singleton_class? is
a bit lengthy Maybe the best name would be just: singleton_class?
So then you would have:
obj = Object.new
c = (class << obj; self; end)
c.singleton_class? # true
class << obj
singleton_class? # true
end
etc. This replaces the explicit "inside" term with the implicit fact
that, inside a class definition, self is the class -- so "insideness"
is already encapsulated in the self mechanism.
(At some point I'll try to go back and look at the examples and figure
out whether I have anything substantive to say about the whole idea
:-)
Trans
Ara.T.How...@noaa.gov wrote:
> anyways... this is the right __behaviour__ if not the right name.
i'll change
> it to inside_singleton? or something in my source.
Are you completely sure? What about these?
class A
# class methods
def self.ic_class
idioclass?
end
class << self
def ic_class2
idioclass?
end
end
# instance method
def ic_instance
idioclass?
end
end
T.
Austin Ziegler
> Ara.T.Howard wrote:
> >
> > this is very useful for meta-programming:
> >
> > class Object
> > def inside_metaclass?
> [...]
>
> > i believe the implementaion is correct iff the following statement is true:
> >
> > all meta-classes descend from the meta-class of Object.
>
..true.
Please stop posting your incorrect statements, Ilias. Just because you
don't understand it doesn't mean that something is false
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Ilias Lazaridis
> On 5/4/05, Ilias Lazaridis <il...@lazaridis.com> wrote:
>>Ara.T.Howard wrote:
>>
>>>this is very useful for meta-programming:
>>>
>>> jib:~/eg/ruby > cat a.rb
>>> class Object
>>> def inside_metaclass?
>>[...]
>>
>>>i believe the implementaion is correct iff the following statement is true:
>>>
>>> all meta-classes descend from the meta-class of Object.
>>
>>the statement is[...]
>
> ..true.
>
> Please stop posting your incorrect statements, Ilias. Just because you
> don't understand it doesn't mean that something is false
A "class" is instantiated to 0..n objects.
A "singleton class" is instantiated to 0..1 object
A "metaclass" is instantiated to 0..n Class Objects
Ruby has no metaclasses.
No one can insist on this.
If it's Mr. Austin Ziegler of Mr. Y. Matsumoto.
-
The correct term would be "exclusive object" (or something similar, but
_not_ metaclass, which has a specific meaning):
The diagramm (V1.3) demonstrates this.
http://lazaridis.com/case/lang/ruby
-
So, readers can now decide who's right and who's false.
.
Hal Fulton
> A "singleton class" is instantiated to 0..1 object
You're thinking of the Singleton pattern, which deals
with a class which can only be instantiated once,
resulting in a single object.
The term "singleton" simply means "something which is
unique or occurs only once."
The term "singleton" is used in the Ruby community to
mean several things:
- an object of a class which can only be instantiated
once (Singleton Pattern)
- a method that is unique to its object, rather than
originating in the class of the object
- an object containing methods that are unique to that
object, i.e., containing singleton methods
When we say "singleton class," we are not really saying
"a class which is a singleton."
In English, the adjective does not always modify the noun
in the same way. "Human Services" means services FOR
humans; a "Reptile Zoo" is a zoo OF reptiles (not one
that we intend reptiles to visit and pay admission).
We use the term "singleton class" not to signify "a class
that is a singleton," but rather to signify "a class where
we store the singleton methods."
To add to the confusion, a class in Ruby is an object. So
when is a class anything *but* a singleton? Is there more
than one occurrence of Fixnum in Ruby? I suppose we could
do Fixnum.dup and there would be.
In short, the Ruby community's usage is not 100% in line
with the rest of the CS community. But that is OK, because
1) even the CS community at large does use terms with 100%
consistency, and 2) we are using terms for concepts that do
not exist in most other OO languages.
Hal
Hal Fulton
> 1) even the CS community at large does use terms with 100%
> consistency,
I was trying to say: does NOT use terms with 100% consistency.
Hal
Ilias Lazaridis
> Ilias Lazaridis wrote:
>
>> A "singleton class" is instantiated to 0..1 object
>
> You're thinking of the Singleton pattern, which deals
> with a class which can only be instantiated once,
> resulting in a single object.
=> resulting in a "singleton object"
> The term "singleton" simply means "something which is
> unique or occurs only once."
of ocurse.
> The term "singleton" is used in the Ruby community to
> mean several things:
>
> - an object of a class which can only be instantiated
> once (Singleton Pattern)
ok
> - a method that is unique to its object, rather than
> originating in the class of the object
=> singleton method
> - an object containing methods that are unique to that
> object, i.e., containing singleton methods
[...] - (attemp to justify duplicate meaning of terminology)
"Singleton Class" is a defined terminology.
I will not use it, simply because a confused language-designer has
defined it that way.
[btw: the central point of this thread is the false usage of the term
"metaclass"]
.
Yukihiro Matsumoto
In message "Re: [RCR] Object#inside_metaclass?"
on Thu, 5 May 2005 00:05:10 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
|"singleton class" has already a meaning within OOP.
|like this: "a class which has only one instance"
According to the Design Pattern book, right?
Interestingly, I started to use the term before the book was published
in 1995. Sad coincidence.
matz.
Ilias Lazaridis
> Hi,
>
> In message "Re: [RCR] Object#inside_metaclass?"
> on Thu, 5 May 2005 00:05:10 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
>
> |"singleton class" has already a meaning within OOP.
> |like this: "a class which has only one instance"
>
> According to the Design Pattern book, right?
I don't know this book.
> Interestingly, I started to use the term before the book was published
> in 1995. Sad coincidence.
I understand.
But makes it any sense to insist on that?
Or makes it sense to change the terminology, thus it doesn't conflict
with this:
http://www.google.com/search?q=singleton+class
ensuring this way a simpler teach-in to ruby?
Please act, and initialize a terminology change.
-
If you like, contact me via private email thus we can discuss the issue
non-public.
.
Yukihiro Matsumoto
|> Interestingly, I started to use the term before the book was published
|> in 1995. Sad coincidence.
|
|I understand.
|
|But makes it any sense to insist on that?
Until we find a better term. I don't think other terms proposed such
as "exclusive class" are better. I assume Ruby users smart enough to
deal with them by context until the time.
matz.
Ilias Lazaridis
> In message "Re: [RCR] Object#inside_metaclass?"
> on Sat, 7 May 2005 21:14:22 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
>
> |> Interestingly, I started to use the term before the book was published
> |> in 1995. Sad coincidence.
> |
> |I understand.
> |
> |But makes it any sense to insist on that?
>
> Until we find a better term.
who is "we"?
The Japanese language development list?
"Please act, and initialize a terminology change."
here, in the core of the ruby community.
> I don't think other terms proposed such
> as "exclusive class" are better.
even the term "bingo-bongo class" is better.
> I assume Ruby users smart enough to
> deal with them by context until the time.
There are newcomers.
You should show more respect against them.
.
Yukihiro Matsumoto
In message "Re: [RCR] Object#inside_metaclass?"
|> I don't think other terms proposed such
|> as "exclusive class" are better.
|
|even the term "bingo-bongo class" is better.
This statement implies you think avoiding name conflict is more
important than how terms describe the concept. I think otherwise.
I should not have named my language "Ruby" if I followed your opinion;
perhaps, it would be "bingo-bongo".
|> I assume Ruby users smart enough to
|> deal with them by context until the time.
|
|There are newcomers.
I assume most of newcomers are capable to understand the term very
quick. Am I too optimistic?
matz.
Ilias Lazaridis
> In message "Re: [RCR] Object#inside_metaclass?"
> on Sat, 7 May 2005 22:44:22 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
>
> |> I don't think other terms proposed such
> |> as "exclusive class" are better.
> |
> |even the term "bingo-bongo class" is better.
>
> This statement implies you think avoiding name conflict is more
> important than how terms describe the concept.
Avoiding name conflict is essential for any recognition process.
This is too essential to even discuss it here.
> I think otherwise.
even if:
the term "singleton class" is still false.
A "class" has instances.
The "singleton class" has not.
> I should not have named my language "Ruby"
this is not "your" language.
You've integrated existing concepts [which have existing terminology].
Possibly you've added new concepts (without researching enouth to find
concise new terminology).
[of course there's the possibility, that the plan was to implement e.g.
real "metaclasses", but you've failed to do so. Then you have to clarify
this]
> if I followed your opinion;
"Ruby" was not used in the Domain (or Namespace) "Programming Languages".
Thus you was free to name it "Ruby".
> perhaps, it would be "bingo-bongo".
This is nonsense.
> |> I assume Ruby users smart enough to
> |> deal with them by context until the time.
> |
> |There are newcomers.
>
> I assume most of newcomers are capable to understand the term very
> quick. Am I too optimistic?
no.
Just too egocentric.
Perhaps a little bit stubborn?
Maybe arrogant?
.
Yukihiro Matsumoto
In message "Re: [RCR] Object#inside_metaclass?"
on Sun, 8 May 2005 02:24:25 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
|the term "singleton class" is still false.
|
|A "class" has instances.
|
|The "singleton class" has not.
I'm not sure what you meant. If "singleton class" exists, it has an
instance. It would be an object of which the singleton class holds
attributes.
|You've integrated existing concepts [which have existing terminology].
Then tell me the "existing" term for this concept, which I failed to
find in the past. I don't think "exclusive class" is it.
I'm not going to discuss about my personality. It's too off topic
here.
matz.
Austin Ziegler
>|> I assume Ruby users smart enough to
>|> deal with them by context until the time.
>|There are newcomers.
> I assume most of newcomers are capable to understand the term very
> quick. Am I too optimistic?
Not at all.
I don't think that anyone else who has come to Ruby and posted on
ruby-talk in the last three years -- how long I think I've been
around -- has not grasped this after a single round of emails.
Let me rephrase that for clarity: in my memory of the last three
years, the person to whom you responded is the only person who
continues to insist that this term is confusing and is a problem.
There is the ongoing discussion about whether there might be a
better term, but no one, at least as far as I can read, is
*confused* about the meaning here.
Ilias Lazaridis
> Hi,
>
> In message "Re: [RCR] Object#inside_metaclass?"
> on Sun, 8 May 2005 02:24:25 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
>
> |the term "singleton class" is still false.
> |
> |A "class" has instances.
> |
> |The "singleton class" has not.
>
> I'm not sure what you meant.
I'm sorry, I was not precise:
I meant:
The [Ruby] "singleton class" has not.
> If "singleton class" exists, it has an
> instance. It would be an object of which the singleton class holds
> attributes.
But this object is _not_ an instance of the "singleton class".
There is a relation, but not an OO 'instance of' one.
Concretely, in the diagramm V1.3 this means:
"john" is an instance of class "Talker"
"john" has somehow a dependency to the "singleton class" (exclusive
class) "class:talker:john"
http://lazaridis.com/case/lang/ruby/index.html
"class:talker:john" has _no_ observable instances.
[thus it's not a class, and thus "exclusive class" is somehow a bad naming]
> |You've integrated existing concepts [which have existing terminology].
>
> Then tell me the "existing" term for this concept, which I failed to
> find in the past.
I don't know it yet.
> I don't think "exclusive class" is it.
I agree with you, "exclusive class" isn't the perfect pick.
[although it comes close]
I've prepared a new thread with a new suggestion, but currently there's
too much noise on the list.
I will post it later(~3h) or tomorrow (~ 20h).
> I'm not going to discuss about my personality. It's too off topic
> here.
you have startet this with: "Am I too optimistic?"
and: essentially it's not off-topic (as your personality is directly
related with this topic), but I will respect you wish.
.
Jon A. Lambert
>
> There is a relation, but not an OO 'instance of' one.
>
> Concretely, in the diagramm V1.3 this means:
The answer is really very simple, and much as I loathe to repeat it again
(well not really)
UML is broken!
If it cannot model Ruby correctly then it cannot be "unified".
Bug Booch and Rumbaugh about their arrogance.
ObNotetoHonorableMrMatsumoto:
Not sure if it was a typo but "mataclass" is perfect.
--
J Lambert
Mark Hubbart
> the term "singleton class" is still false.
This is the only part I want to comment on. You keep using the word
false, when you mean either "imprecise" or "wrong". Your own usage of
the word "false" is, in itself, extremely imprecise. Any english
speaker is probably laughing at the usage whenever they see you use
it, and probably most of the non-native english speakers as well.
False means "untrue". An assertion can be described as either true or
untrue; a term can only be described by it's level of precision, not
it's veracity (though, an assertion that the term is precise could be
contested on it's veracity).
Constraining yourself to using precise terminology while complaining
about the precision of terminology seems rather important. But then,
hey, I may be wrong.
Also, insulting someone (especially someone who has not insulted you)
is rude. Especially when they don't really *have* to talk to you in
the first place, and are only doing it because they are very polite.
If you must post on this list, please try to be civil, at least
towards those who are civil towards you.
cheers,
Mark
Ilias Lazaridis
> On 5/7/05, Ilias Lazaridis <il...@lazaridis.com> wrote:
>
>>the term "singleton class" is still false.
>
> This is the only part I want to comment on. You keep using the word
> false, when you mean either "imprecise" or "wrong". Your own usage of
> the word "false" is, in itself, extremely imprecise. Any english
> speaker is probably laughing at the usage whenever they see you use
> it, and probably most of the non-native english speakers as well.
ok
> False means "untrue". An assertion can be described as either true or
> untrue; a term can only be described by it's level of precision, not
> it's veracity (though, an assertion that the term is precise could be
> contested on it's veracity).
>
> Constraining yourself to using precise terminology while complaining
> about the precision of terminology seems rather important. But then,
> hey, I may be wrong.
No, you are right.
non has complained till now.
-
faulty, deficient, defectively
I think I will use faulty.
Thank you for your constructive criticism.
> Also, insulting someone (especially someone who has not insulted you)
> is rude. Especially when they don't really *have* to talk to you in
> the first place, and are only doing it because they are very polite.
I've not insulted anyone.
> If you must post on this list, please try to be civil, at least
> towards those who are civil towards you.
I don't have to try this.
I simply do it.
> cheers,
> Mark
.
gabriele renzi
<snip all>
Well, let me say this is one of the best examples of self control I've
ever seen.
Matz, congrats you are some kind of good karma generator :)
Yukihiro Matsumoto
In message "Re: [RCR] Object#inside_metaclass?"
on Sun, 8 May 2005 04:09:28 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
|> If "singleton class" exists, it has an
|> instance. It would be an object of which the singleton class holds
|> attributes.
|
|But this object is _not_ an instance of the "singleton class".
Not, in your diagram and definition, and not, in my explained language
model. But virtually everyone except us (me and you, Ilias) seem to
have the other model in mind. The object is an instance of the
singleton class in that model. It is also in the current
implementation of the interpreter. I'm thinking of changing the
definition to confirm model in others' mind, since the other model.
Under the new model, horizontal arrows in the object.c diagram mean
instance-of relations.
The obstacle is that if I choose the new model, I have to name an
official name to "singleton class", which I agree is not the best term
for it.
|> |You've integrated existing concepts [which have existing terminology].
|>
|> Then tell me the "existing" term for this concept, which I failed to
|> find in the past.
|
|I don't know it yet.
Then please come back again when you find the name, preferably
suitable under the new model.
matz.
Saynatkari
Le 8/5/2005, "Yukihiro Matsumoto" <ma...@ruby-lang.org> a écrit:
>Ilias,
>
>In message "Re: [RCR] Object#inside_metaclass?"
> on Sun, 8 May 2005 04:09:28 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
>
>|> If "singleton class" exists, it has an
>|> instance. It would be an object of which the singleton class holds
>|> attributes.
>|
>|But this object is _not_ an instance of the "singleton class".
>
>Not, in your diagram and definition, and not, in my explained language
>model. But virtually everyone except us (me and you, Ilias) seem to
>have the other model in mind. The object is an instance of the
>singleton class in that model. It is also in the current
>implementation of the interpreter. I'm thinking of changing the
>definition to confirm model in others' mind, since the other model.
>Under the new model, horizontal arrows in the object.c diagram mean
>instance-of relations.
People have a tendency to find complexity where there is none :)
As far as a new model goes, I would assume everyone will be
happy as long as one can metaprogram as easily as currently.
>The obstacle is that if I choose the new model, I have to name an
>official name to "singleton class", which I agree is not the best term
>for it.
>
>|> |You've integrated existing concepts [which have existing terminology].
>|>
>|> Then tell me the "existing" term for this concept, which I failed to
>|> find in the past.
>|
>|I don't know it yet.
>
>Then please come back again when you find the name, preferably
>suitable under the new model.
Etymologically, 'idioclass' (as in an 'idiom') is probably the most
suitable choice [1]. There was also a poll of some sort on Rubyforge,
I think, if you want to see folks weighing in on their choice.
> matz.
E
--
template<typename duck>
void quack(duck& d) { d.quack(); }
Ilias Lazaridis
> Ilias,
>
> In message "Re: [RCR] Object#inside_metaclass?"
> on Sun, 8 May 2005 04:09:28 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
>
> |> If "singleton class" exists, it has an
> |> instance. It would be an object of which the singleton class holds
> |> attributes.
> |
> |But this object is _not_ an instance of the "singleton class".
>
> Not, in your diagram and definition,
My diagramm reflects the current OO-observable implementation of ruby
(=reality).
> and not, in my explained language model.
=> "explained language model", where?
> But virtually everyone except us (me and you, Ilias) seem to
> have the other model in mind.
This is irrelevant.
Of course they have to adjust their minds to the _real_ existent model
and implemented model (see "explained language model" and see diagramm)
> The object is an instance of the singleton class in that model.
ok
> It is also in the current implementation of the interpreter.
ok [internally, non observable.]
> I'm thinking of changing the
> definition to confirm model in others' mind, since the other model.
I sense a problem - but cannot explain it.
> Under the new model, horizontal arrows in the object.c diagram mean
> instance-of relations.
I understand.
> The obstacle is that if I choose the new model, I have to name an
> official name to "singleton class", which I agree is not the best term
> for it.
ok
> |> |You've integrated existing concepts [which have existing terminology].
> |>
> |> Then tell me the "existing" term for this concept, which I failed to
> |> find in the past.
> |
> |I don't know it yet.
>
> Then please come back again when you find the name, preferably
> suitable under the new model.
You sent me away to make this research myself?
I suggest Collaboration.
As you see, I open the results _and_ my understanding process thus
others can benefit from it [although their ego won't mostly not let them
admit this]
I depend on some answers to analytical questions to complete earlier.
I don't think that it would be fair to figure out things instead of
simply asking them.
Please look at the new thread:
[ETYMOLOGY] - Sterile Classes / Sterile Meta Classes
http://groups-beta.google.com/group/comp.lang.ruby/msg/fc3ff9ed91d7a827
It would be nice if you could comment on the plans within this thread.
I could then prepare an updated diagramm.
.
Ilias Lazaridis
> Yukihiro Matsumoto ha scritto:
> <snip all>
>
> Well, let me say this is one of the best examples of self control I've
> ever seen.
Not exactly.
It is an example of an efficient, slightly emotionally loaded but
self-regulating public conversation [which remained nearly uninterupted].
> Matz, congrats you are some kind of good karma generator :)
.
Yukihiro Matsumoto
In message "Re: [RCR] Object#inside_metaclass?"
on Sun, 8 May 2005 23:44:23 +0900, Ilias Lazaridis <il...@lazaridis.com> writes:
|> Then please come back again when you find the name, preferably
|> suitable under the new model.
|
|You sent me away to make this research myself?
No. I will seek for myself. But to tell the truth, I don't hope
much, since I have never had a better term than 'singleton class'
after the years of seeking "the term". You may have fresh idea.
|[ETYMOLOGY] - Sterile Classes / Sterile Meta Classes
I don't think these are better for good reasons. I will follow up in
that thread.
matz.