Fwd: {FalconPL} enumerator callback question

[Giancarlo Niccolai]

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.


-------- Original Message --------

Subject:	{FalconPL} enumerator callback question
Date:	Mon, 16 Jan 2012 21:43:56 -0500
From:	Paul Nema <paul...@gmail.com>
Reply-To:	falc...@googlegroups.com
To:	FalconPL <falc...@googlegroups.com>

Updating classes, like classstring.cpp, classarray.cpp, etc.

For function: void ClassString::enumerateProperties( void*, Class::PropertyEnumerator& cb ) const

PropertyEnumerator operator cb is called for each class method.

Class String has 26 methods, so 26 cb calls (I.E. cb( "methodName", false ); etc+25 ) each time this class is instantiated.

Could be expensive when creating a lot of arrays.

There are more efficient way to perform this.

Examples:

1. A comma delimited string of methods

2. Pass an array of methods

3. Something else? etc.

Probably a reason for the current design as opposed to the above suggestions.  If so please elaborate.  If not let me know and I explore how to update enumerator.h

Thanks

--
You received this message because you are subscribed to the Google Groups "FalconPL" group.
To post to this group, send email to falc...@googlegroups.com.
To unsubscribe from this group, send email to falconpl+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/falconpl?hl=en.