From: Donal F. <don...@ma...> - 2024-09-11 15:52:47
|
This is a ping to remind people that I'm still looking for input on what is needed for a C API for properties. I've a bunch of internal APIs that could be exposed, but I don't know what's needed, and I know that what's there right now is not what Tk megawidgets need (there are incompatible properties models between Tcl channels and Tk widgets; you can't have both on the one object because the 'configure' responds quite differently). Primary requirement (the things that I think TclOO should provide itself): * Property discovery mechanism, possibly with enhancement for another property category beyond "supports read" and "supports write". Otherwise simply discovering this stuff from a class hierarchy is really expensive; TclOO tries to minimise class hierarchy trawls. Secondary requirement (the things that TclOO does for its own Tcl-like properties): * Scheme for defining property implementations and calling them. This part actually shouldn't need any special API other than maybe a little trickery to avoid having to dip fully into Tcl_EvalObjv to invoke methods. All the tools for this should either already be there or be something that can be added easily enough. You'll need conventions for what to call these methods; as long as they're not exported the convention can be almost anything. Note that the original implementation of the secondary parts was nearly entirely in Tcl scripts. It's a good way to get this sort of thing started. And classic Tk doesn't have any of this problem anyway by virtue of not doing subclasses in a user-exposed fashion at all. If there's something that seems obvious to you but I've missed, or that seems mystifying to you and I've not talked about in enough detail, let me know. Donal. From: Donal Fellows <don...@ma...> Sent: 27 July 2024 11:58 To: tcl...@li... Subject: [TCLCORE] TclOO Properties C API, request for help/use cases/ideas I've been considering adding a C API for TclOO properties. The issue is I'm trying to imagine what such an API might be. Clearly, there's going to be something to register a property against a class or object (called something akin to Tcl_RegisterProperty) and some functions to do various lookups (especially of the current lists of properties supported directly on a class or property, and of the full list of properties supported by an instance including via inheritance). But what else? Well, I'll be able to provide an API for making implementations, but that will be very specific to Tcl-ish style properties so I'm not sure of the utility; Tk-like properties will need something different. Indeed, that's why properties are not a base feature of oo::object; the details vary too much. I'm tempted to leave the full property manufacturing code as Tcl-internal (and exposed to scripts of course). My point is I really need some help here to describe what sort of things that are needed by other models of what properties should be. I'm happy for base TclOO to provide support for discovery mechanisms; they're the expensive part if done any other way. But I need to know what I'm missing. If I knew, it wouldn't be missing! Donal. |