[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mapping a setter to its @property
From: |
David Chisnall |
Subject: |
Re: Mapping a setter to its @property |
Date: |
Tue, 14 Jul 2015 09:55:09 +0100 |
Hi,
The runtime exposes a property_copyAttributeList() function, which allows you
to get the attributes of a property, including the setter and getter names.
Note that this is designed to do the property->setter mapping, if you want to
do the inverse then you probably need to iterate over all properties in a class
and build a dictionary (I’d suggest std::unordered_map). You could try a fast
path and assume that setFoo: is the setter for the foo property, and just do a
lookup of the foo property in the setFoo: method, but don’t forget that
property metadata lookup is O(n) in the number of properties on a class, so a
hash table may be better. Of course, given the small numbers, doing a linear
search over a per-class array is probably fine.
I’d also suggest looking at imp_implementationWithBlock, which allows you to
add state to methods, so that you can swizzle out the old method and replace it
with a block that calls the old method. This would save you from having to do
the lookup more than once, as all of the relevant variables would be owned by
the block.
David
> On 13 Jul 2015, at 02:36, Ivan Vučica <address@hidden> wrote:
>
> Hi David,
>
> [cc gnustep-dev@ and Filip explicitly]
>
> Filip is currently working on adding support for @dynamic properties to
> CALayer. http://badc0de.net/r/16
>
> This is based on some very preliminary code I hacked together and #if'ed out
> two years ago.
>
> Would you mind advising if there is some better way to runtime-generate these
> properties than what is currently being done -- iterating through them, then
> using class_addMethod() to add an implementation based on the type of the
> property? (I would be looking in the direction of NSValue to try and
> implement storage for other data types.)
>
>
> Also, as the subject of the mail asks, the implementation currently uses _cmd
> to figure out the property name, then uses this to fetch or store a value in
> a dictionary. This will clearly break with a custom getter/setter name.
>
> I'm not sufficiently familiar with the runtime to suggest something smarter.
> Would you mind suggesting an approach which would let us map a call to a
> setter onto the appropriate @property? Would a dictionary mapping a getter
> name to a property name plus a dictionary mapping a setter name to a property
> name be the right way to go? Or is there something wiser that can be done
> just with 'self' and '_cmd' in the shared getter/setter implementation?
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
-- Sent from my Difference Engine