Ok, so I have a temporary way before you get around to that: can we have a $Camebones::CacheAutoload variable that does this, but document not to use it (and set to zero by default) if you ever have to subclass controls (or whatever the docs need to say)?
On 10 Nov 2010, at 18:52, Sherm Pendley <sherm.pendley@...> wrote:
> On Wed, Nov 10, 2010 at 4:34 PM, Matt Sergeant <matt@...> wrote:
>> OK, I found an example where SUPER:: is used (TransparentWindow)
> In that example, SUPER isn't used in a way that will cause problems.
>> # don't cache calls with SUPER in - everything else we can cache...
> We can't cache the value of $isSuperMethod at all, regardless of
> whether it's true or false.
> Cached calls without SUPER in them will always result in calls to
> objc_msgSend(). That will be a problem when those same methods are
> called later, *with* SUPER, when they'd need to be dispatched with
> objc_msgSendSuper() instead. Likewise the other way around. The
> decision of which dispatch function to use can't be made just once,
> when the closure is created - it has to be made every time the closure
> is called.
> I have some thoughts about how to deal with this in Mac::BridgeSupport
> (essentially the module part of CamelBones 2.0), but it involves more
> than just an easy patch to CamelBones.pm. In that, I plan to walk the
> ObjC runtime when the module first loads, and use newXS() to create
> methods that directly call CBCallNativeMethod() - no more AUTOLOAD at
> With CBCallNativeMethod() being called directly by client code (rather
> than indirectly, by way of AUTOLOAD or a cached sub), it will have
> easy access to the CV* by which it was called. With that, it can find
> out what package it's in, call that class' -methodForSelector: or
> +instanceMethodForSelector: to get a pointer to the required function,
> then call that function directly. Basically, it would take advantage
> of the tree-climbing and method resolution that Perl has already done,
> rather than using the ObjC runtime to repeat the same work.
> It can also use CvXSUBANY(cv).any_ptr to store a pointer to a meta
> data struct. Some of that structs members can be populated when the
> xsub is created, and others lazily, the first time it's called. The
> ObjC selector, for example, will need to be stored there when the xsub
> is created, and type strings can be parsed into a more-efficient
> structure that's cached when the method is called the first time.
> Cocoa programming in Perl: