From: Robert Klemme <shortcutter@...>
Date: 2011-03-27T02:35:27+09:00
Subject: Re: Dynamic classes

On 26.03.2011 15:38, Vicente Bosch Campos wrote:
> I understand how it works at the moment. Still if you are doing
> metaprogramming and consider with a very purist perspective that
> everything is an object then a Class definition is just an instance
> of the Class Class

The definition is a definition, the _result of executing it_ is an 
instance of class Class.

> and I should be able to change its properties and
> that should be independent of having the definition assigned to a
> variable otherwise it would be discarded as you say.

You can change a class's properties, e.g. by adding methods etc.  It's 
just that the name happens to be a read only property and there is some 
additional magic which will set it on first constant assignment.  I 
don't see how that collides with a "purist perspective".

> Did a bit of reading and at the end you can also create a class in
> the following manner which allows you to define a name dynamically
> with out using eval:
>
> Object.const_set("Bar",Class.new)

See my posting in this thread from yesterday. :-)

Oh, and btw, that code does not really make sense that way because it 
can be easily replaced by

Bar = Class.new

or even

class Bar
end

The approach with Object.const_set basically only makes sense if the 
name is dynamic, too.

Everything can be done on a low level but usually we define artifacts 
(classes, methods) to group functionality so we can access it more 
conveniently and manage complexity.

> This is due (from my opinion) to how the vm stores the classes as
> constants in Object.

I find that wording slightly irritating: it sounds a bit as if you 
assume the class is somehow in the constant.  In Reality the constant 
just references the class instance.  There is no particular magic 
involved other than the custom syntax with "class Name...end".

> I understand why but I think there should be a
> more cleaner,abstract way to create Class definitions as they are
> objects instead of the current Bare metal approach ( we get to see to
> much of the internals ?)

I am not sure what you mean by "too much internals".  After all, I would 
consider doing

Foo = Class.new do
   def x;123;end
end

more bare metal than

class Foo
   def x;123;end
end

Syntax with "class" certainly helps makes things a bit more abstract and 
less "internal".  What would be the cleaner, more abstract way?

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/