On 26.03.2011 15:38, Vicente B. 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.
I agree with you.
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”.
I have not explained my self properly. Imagine we are talking about
making an instance of any other object e.g. a Car and the car has a name
and it allows you reference the car instance by it in the future.
Would you prefer the car name is defined by the variable that contains
it or by setting the name in the constructor?
hotwheels = Car.new
current_car = Car.new(“hotwheels”)
I don’t think anyone would understand directly that I have automatically
set a property inside my car with the variable name. It would be a bit
counterintuitive and different from how any other instance properties
work on this class and how they are usually set on any other type of
object of any library.
Considering the Class to be an object too by not allowing me set the
name at the .new and taking the name of the left hand side of the
equality sign in case it is a Constant ( otherwise it does not) it is
not acting very much like any other object.
Bar = Class.new
or even
class Bar
end
The approach with Object.const_set basically only makes sense if the name is
dynamic, too.
Yes sorry, I do want to have the name dynamic too ( I might be going
off-topic for the original post, sorry).
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”.
Agreed, its just a reference. But if I want to have a dynamic name
without having to use eval I need to understand that the list of classes
defined are referred to as constants in the Object and I can do that
with
Object.const_set(“Bar”,Class.new)
I am just saying it would be nicer to do Class.new(“Bar”) would be much
more like any other object instantiation and less questioned about as it
would not be an exception to how the rest of the stuff works ( although
Class object is truly a bit of an exception and its one of those
marvelous things ruby allows us to tinker with ).
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
By “too much internals” I mean that I actually need to get to know that
the class Names are referenced in a list of constants in Object and that
I can do Object.const_set(“Bar”,Class.new) to create a class with a
dynamic name ( and not have to use eval) instead of Class.new(“Bar”).
( Sorry for going in circles)
Syntax with “class” certainly helps makes things a bit more abstract and less
“internal”. What would be the cleaner, more abstract way?
For a definition with a set name totally agree with you.
Cheers
Many thanks for the healthy discussion 
Cheers
Vicente