It's true that the callback method is a bit inefficient in terms of CPU
cycles, but a Class is istantiated only once per program. The instances
are instantiated multiple times, but they aren't created using the
property enumerator system. The property enumeration is called only when:

- A dynamic class as FalconClass or HyperClass is created (again, once
per program)
- A third party module or entity wants to have meta-information about a
class.

Instances are created calling the op_create of the class. You can easily
see that op_create knows the structure of the object it creates: either
statically, because it has a pointer to the kind of entity it is
creating, or dynamically, because enumerate() has been previously used
to create a meta-information that is then used.

You'll also notice that, actually, the creation of FalconClass or
HyperClass is rare (none is in the library). The vast majority of
classes exposed to programs are ClassUser or directly deriving from Class.

The rationale for the enumeration policy is twofold:
- It hides the internal representation of the data.
- It is memory effective (while being cpu intensive). Most of all, it
doesn't require any dynamically allocated memory to provide
meta-information on a class.

Hiding the internal representation of the data is important, because you
might have classes that simply reflect some internal aspect of an host
program (embedding app), while others may be more sophisticated and
present dynamic properties and methods, allowing the user to create new
properties and methods at runtime. The embedding app classes may just
want to provide properties callback events at op_getProperty, where
dynamic classes need to have an internal dynamic map of properties.

However, now that the Class interface has been stabilized and the
(non-trivial) problems in creating HyperClasses is solved, we may go for
something more static. While the solution of having a property-method
map dynamic map is sometimes sub-optimal, we may decide that it's a
sensible way to standardize the class behavior.

The problem is that the map should not be exposed to the final program
as-is, unless we create a separate map interface (similar to the
ItemArray interface).

I don't have a definite position on this issue. It's data driven (define
the prop map) vs. code driven (respond to op_getProperty, hasProperty,
propertyEnumerator). ClassUser already superseeds the code-driven
approach with a data-driven one, and that's a Good Thing, so I am open
to comments (but, be sure to look up ClassUser before commenting on, so
we can work on a solid base).

Gian.