Thread:Extension talk:PhpTags/Designing APIs in PhpTags extensions: limitations and best practices/reply (2)

Looks good, more elegant than the old approach. It seems simpler, with (nearly) all registration of classes, functions, constants, etc., unified with the argument and type check info.

The one exception seems to be constants defined through a callback, to allow the dynamically determined constants in PhpTags Wiki. I don't know how useful it would be to make dynamically generated registrations more general, but if it sounds worthwhile, the following comes to mind. Rather than having callbacks specifically for constants, there could be callbacks that fill in (either receiving and using, or constructing and returning) a general data structure, which corresponds to what is loaded from a JSON file. Then callbacks could add anything which PhpTags supports but which is not known in advance.

Thanks for the info on PhpTagsFuncNativeObject. I'm guessing that objects using it would also be described in the JSON file, though it's currently not included in the draft change you linked to for PhpTags Functions.

As for PhpTags SMW, I'll make sure parameter handling is more sane in the next version. It will use different classes, with a different design (in the process of being worked out), and checking should end up much simpler.

One comment on the PhpTagsHooks API, now that you're changing it: it may make sense to call the public "set..." methods "add..." or "register..." instead, since they do not replace anything, but instead add/register things.

Finally, I had another series of ideas in considering the new design you're describing and working on. However, these ideas only add things on top of the design, and I don't know how useful they might be. Here's a list of them in case there's something of value in it: Those are the ideas, whether useful or not.
 * Simplifying implementing configuration options for what is loaded in extensions: Entries in the JSON file could optionally specify a check (callback function) which runs at data loading time, and determines whether or not to add the data for the entry. (But an extension doing this would then have to make sure that for each configuration, a unique key is used for the JSON file, so that old cached data is not reused when configuration changes.)
 * Alternative to the above: using checks in Runtime instead. (No need for changing the key, but some added overhead.) This would also allow, for example, restricting the use of unsafe things to secured namespaces (or using some other criteria). The idea is that such checks can be specified per object, method, function, etc., and the same checking callback can be used everywhere it applies.
 * Building upon the example of secured namespaces, support for those in PhpTags itself: There could be a setting for "secured namespaces", similar to the already existing namespace setting, but also meaning that otherwise restricted things should be allowed in those namespaces. The idea is that things can be marked restricted in the JSON file. When PhpTags is used, it would then check the namespace and allow or deny use of restricted things accordingly. (The advantage of support in PhpTags itself is a single setting for secured namespaces that can be used by all extensions.)

Hope you have a good time as well!