Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support @properties that are 'copy' in addition to the default 'retain' #41

Closed
seanm opened this Issue Dec 7, 2010 · 12 comments

Comments

Projects
None yet
5 participants
Contributor

seanm commented Dec 7, 2010

mogenerator always creates properties that are 'retain', which is a sensible default, but I'd like to see it able to generate 'copy' properties too.

Perhaps this could be done using the user info dictionary, like how transformable attributes can specify an 'attributeValueClassName' key/value pair.

Owner

rentzsch commented Dec 8, 2010

I'm down with that, implementing it the way your described. I'd accept such a patch if you want to work it up. :-)

Contributor

seanm commented Dec 8, 2010

Cool. I could try, but won't have time for a few weeks. I wanted to at least get the ball rolling with this bug entry.

So how about key 'attributeValueSetterSemantics' where the value can be 'retain' or 'copy', and if there's no value it defaults to retain?

Owner

rentzsch commented Dec 8, 2010

I know about the busy thing :-) attributeValueSetterSemantics sounds fine.

Owner

rentzsch commented Jan 7, 2012

Sounds like #84 supersedes this issue? Should I close it?

Contributor

seanm commented Jan 9, 2012

I don't think they're the same, but certainly related.

Regardless of memory model, there is a difference between copying and referencing an object.

It could still be useful, IMHO, it be able to tag an attribute as either 'copy' or 'retain aka strong'.

Here's a first shot: https://github.com/diederich/mogenerator/tree/propertiesWithCopy
Instead of allowing to define retain/copy in the userInfo dictionary, this approach uses a boolean value. I'm not sure if this is a good approach, but it works for the above example, as "strong" implies copy. Though others like weak, __unsafe_unretained might be interesting for the PONSO templates.

My current use case for this is an NSManagedObject which should implement a protocol that defines a property with copy semantics.

Contributor

seanm commented Mar 13, 2012

What do the two states of your boolean represent? What do you mean "strong implies copy"?

The state says either to use copy semantics or not.
If it's set to yes, the property is declared as

@property (nonatomic, copy) <Type> <Name>;

if set to no it's dependent on ARC. If ARC is enabled it's

@property (nonatomic, strong) <Type> <Name>;

without ARC it's

@property (nonatomic, retain) <Type> <Name>;

So there's no special case for ARC and copy. If you declare a property as with copy semantics, strong is implicitly added (http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership.spelling.property)

honus commented Jun 24, 2012

I think you meant to say "copy implies strong" not "strong implies copy".

Definitely, thanks.

Owner

rentzsch commented Jan 14, 2013

related: #84

@ghost ghost assigned rentzsch Jan 14, 2013

@tibr tibr added a commit to tibr/mogenerator that referenced this issue Apr 10, 2013

@tibr tibr Add custom attribute setter semantics.
The memory management attribute of a property can now be set by using
the key "attributeSetterSemantics". If it is not set, it defaults to
strong/retain. This does not work for relationships!

References #41, #84
71ee5e8
Collaborator

justin commented Dec 26, 2015

This is ancient. Closing it out. If its still an issue for you, please open a new issue.

@justin justin closed this Dec 26, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment