Re: @dynamic property synthesis

[David Chisnall]

Hi Ivan,

You seem to be very, very confused and none of the documentation that you cite 
says what you seem to think it says.

@dynamic does not mean run-time synthesized, it means the exact opposite, as I 
said.  @dynamic is just a hint to the compiler that you are providing the 
implementation of the property (possibly in a superclass, possibly in a 
category) and that it should not complain if it can't see one, nor should it 
try to synthesise one if you are in a synthesis-by-default mode (recent 
versions of clang default to synthesising properties if they don't see 
implementations or @dynamic).

And, as I suspected, you are confusing properties with KVC (Key-Value Coding), 
or, perhaps more relevantly, with KVO (Key-Value Observing).  CoreAnimation 
makes heavy use of both KVC and KVO for animatable properties.  Note that the 
CoreAnimation documentation occasionally uses the term 'properties' in the 
traditional way, rather than referring to declared properties.

For a property to be used for animation, it must be KVC-compliant, so that CA 
can set it, and KVO compliant, so that CA can receive notifications when it 
changes.  Again, this does not require any method synthesis at run time.  

If you read the two links you posted carefully, then you will see that they say 
nothing like what you seem to believe that they say.  They explicitly deal with 
the case where methods do not exist (@dynamic is used to ensure that it does 
not), and so the first path in Core Animation fails.  Trying to animate a 
property with no corresponding setters and getters, CoreAnimation will enter 
into one of the fall-back mechanisms, either one provided by KVC/KVO or its 
own, which is very similar but a bit less general (and therefore, in theory at 
least, faster).  

As I said before, you do not need to add methods at run time.  You simply need 
to implement the case when you try to set a property that does not have a 
corresponding method.  The Omni link explicitly tells you that this stuff is 
all done using KVC...

The examples use declared properties for simplicity, because they are using it 
as a way of providing type information to KVC.  I don't think our KVC 
implementation actually makes use of property metadata in this way, so that's 
something that you could look at fixing, although I think property 
introspection only works with clang and the GNUstep runtime...

David

On 5 Aug 2012, at 21:46, Ivan Vučica wrote:

> Hi David,
> 
> On Sunday, August 5, 2012, David Chisnall wrote:
> Hi Ivan,
> 
> Your question is strange because @dynamic is the opposite of @synthesize.  If 
> what you meant was 'can we use declared properties' then the answer is that 
> we've been able to with clang and the GNUstep runtime for ages, and with GCC 
> since 4.6.
> 
> There is no such thing as 'runtime-generated @properties', the compiler is 
> responsible for generating these functions, although it does call out to the 
> runtime for some simple cases to avoid burning instruction cache for no 
> reason.  Glancing over the CALayer class reference, they all look like 
> properties that will work with trivial @synthesized implementations.
> 
> Most definitely they would.
> 
> Except, app developer-supplied CALayer subclasses can define additional 
> animatable properties, then hand them off for run-time synthesis (as opposed 
> to compile time synthesis) via @dynamic.
> 
> Similar to what Core Data does: properties are not synthesized at compile 
> time via @synthesize, nor are accessors implemented by the app developer. We 
> could in theory suggest developers to simply @synthesize when compiling for 
> GNUstep (our implementation doesn't distinguish between animatable and 
> non-animatable layer properties), but we should aim for source-level 
> compatibility where possible.
>  
> 
> Glancing over your last commit, I can't even begin to work out what you think 
> you are trying to do, but it looks like whatever it is you are not doing it 
> in a sensible way.  Either you are confusing KVC with declared properties, or 
> you don't understand what @dynamic means.  A CoreAnimation implementation 
> does not need these contortions.
> 
> Core Animation implementation by itself does not. However, multiple books 
> mention that new animatable properties can be added as described above.
> 
> I pretty much would not support this if I designed an API from scratch. 
> However -- if I understood docs correctly, that's the documented way to add 
> new animatable properties. What I did in the commit you're commenting was 
> pretty much the only way I found of adding accessor methods at runtime, and 
> it being so convoluted is the exact reason why I decided to ask for tips.
> 
> If someone has worked on adding accessor methods at runtime for properties 
> that were marked with @dynamic, I wouldn't mind help. :-)
> 
> More info on what behavior I'm trying to support:
> http://stackoverflow.com/questions/2395382/animating-a-custom-property-of-calayer-subclass
> and to an extent
> http://www.omnigroup.com/blog/entry/Animating_CALayer_content/
> 
> 
> 
> -- 
> Ivan Vučica - ivan@vucica.net
> 
> 


-- Sent from my Cray X1