Adds a nondestructive -attributeTypeName property to attributes #86

merged 4 commits into from Jan 7, 2012


None yet

3 participants


It is usable as a replacement for both -scalarAttributeType and -objectAttributeType, and pulls from the attributeValueTypeName userInfo field if available.

@robrix robrix Adds -attributeTypeName to attributes.
-attributeTypeName uses the “attributeValueTypeName” field in userInfo if available, defaulting to the scalarAttributeType if any, or else the objectAttributeType suffixed with a *.

Intended for use in the templates, deprecating both -scalarAttributeType and -objectAttributeType.

Use case: transformable attributes with “id” as their type (as opposed to the unidiomatic and frankly weird NSObject *).

I should note, this would close #85.

@robrix robrix Adds scalar int*_t support.
This is done by adding -scalarAttributeTypeName, -scalarAccessorMethodName, and -scalarFactoryMethodName to NSAttributeDescription.

-scalarAttributeTypeName returns the same thing as -scalarAttributeType, except that where that uses short, int, and long long, the new method uses int16_t, int32_t, and int64_t.

To allow simple boxing and unboxing with NSNumber, -scalarAccessorMethodName and -scalarFactoryMethodName return the appropriate values for the scalar type, e.g. boolValue, longLongValue, and numberWithShort:.

I did not mean to add the second commit to this pull request! Oh well, it provides a fix for #2. Do with it what you will! I leave my code humbly at your mercy.

@rentzsch rentzsch merged commit c82f11a into rentzsch:master Jan 7, 2012

I found some other issues examining the test mule MOs, which I fixed up here: 25bc9fc

You may want to take a look, especially since I removed support for attributeValueTypeName attribute userInfo key since I couldn't figure how it differs from the existing attributeValueClassName support. Maybe I'm missing something?


Main difference with attributeValueTypeName was that it would allow you to specify e.g. id without having the * appended onto it. attributeValueClassName seems to handle that by replacing NSObject * with id.

On the other hand, other type names would also be possible with attributeValueTypeName that aren’t with this handling of attributeValueClassName, for example Class and id<SomeProtocol>.

The intention was basically “type name, verbatim.” I still kind of feel like this is valuable for the protocol case especially (without resorting to NSObject<SomeProtocol> *), which is something I’ve occasionally wanted. What do you think?

Sorry about the NSNumber mistakes. Derp :)


Ah, I see.

I don't think we need direct "type name, verbatim" support if we keep the generation code smart enough. For instance, I added NSObject* detection, replacing it with an id. So I think we already have all the bases covered with that simple heuristic.

Let me know if you have any other examples that aren't correctly handled.


Oh, I misunderstood your text. Yup, those aren't covered. I'm more inclined to make attributeValueClassName mean "type name, verbatim" than add another userInfo key, and accept the fact folks will need to tweak their model to add the asterisk.


Devil's advocate time, I guess: What's wrong with special-casing an understanding of Class and id and id<ProtocolName[,…]> when generating from an attributeValueClassName? It seems irritating to have to throw asterisks all over the place in userInfo fields in the data model.


@JoeOsborn: yup, I was already thinking along those lines myself. Good to hear you're on the same wavelength.

I'm thinking about something like this (in mostly-JavaScript):

if (attributeValueClassName.match(/Class/)) return attributeValueClassName; // Class
if (attributeValueClassName.match(/</)) return attributeValueClassName; // id<Protocol1,Protocol2>
if (attributeValueClassName.match(/NSObject */)) return "id"; // NSObject *
return attributeValueClassName;
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment