gnustep-dev
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]