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
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
===============================================================================
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 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.
..
--
http://lazaridis.com
That's a very neat approach. Much more satisfying than string-scraping.
martin
···
Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
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
···
On Wed, 4 May 2005, Ara.T.Howard wrote:
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.
--
David A. Black
dblack@wobblini.net
Ara.T.Howard schrieb:
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
i believe the implementaion is correct iff the following statement is true:
all meta-classes descend from the meta-class of Object.
That is plain false (at least in my understanding of what
you are trying
class << Module
···
-a
Ara.T.Howard wrote:
this is very useful for meta-programming:
jib:~/eg/ruby > cat a.rb
class Object
def inside_metaclass?
Why? Any real world samples?
David A. Black 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
..
···
On Wed, 4 May 2005, Ara.T.Howard wrote:
--
http://lazaridis.com
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 jim@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)
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.
-a
···
On Wed, 4 May 2005, Martin DeMello wrote:
Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
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.
--
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
===============================================================================
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.
-a
···
On Thu, 5 May 2005, [ISO-8859-1] Florian Groß wrote:
Ara.T.Howard wrote:
this is very useful for meta-programming:
jib:~/eg/ruby > cat a.rb
class Object
def inside_metaclass?
Why? Any real world samples?
--
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
===============================================================================
...true.
Please stop posting your incorrect statements, Ilias. Just because you
don't understand it doesn't mean that something is false
-austin
···
On 5/4/05, Ilias Lazaridis <ilias@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[...]
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
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
···
On 5/4/05, Jim Weirich <jim@weirichhouse.org> 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. 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.
Ara.T.Howard@noaa.gov schrieb:
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
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?
@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?
David
···
--
David A. Black
dblack@wobblini.net
Hi --
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...
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.
David
···
On Thu, 5 May 2005, Mark Hubbart wrote:
On 5/4/05, Jim Weirich <jim@weirichhouse.org> wrote:
--
David A. Black
dblack@wobblini.net
David A. Black said:
Hi --
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.
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.
···
On Thu, 5 May 2005, Jim Weirich wrote:
--
-- Jim Weirich jim@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"
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
it's not easy...
-a
···
On Thu, 5 May 2005, Christoph wrote:
Ara.T.Howard@noaa.gov schrieb:
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
--
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
===============================================================================