Skip to content

Adds a nondestructive -attributeTypeName property to attributes #86

Merged
merged 4 commits into from Jan 7, 2012

3 participants

@robrix
robrix commented Jan 7, 2012

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 *).
01e5043
@robrix
robrix commented Jan 7, 2012

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:.
fd2b556
@robrix
robrix commented Jan 7, 2012

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
@rentzsch
Owner
rentzsch commented 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?

@robrix
robrix commented Jan 7, 2012

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 :)

@rentzsch
Owner
rentzsch commented Jan 8, 2012

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.

@robrix
robrix commented Jan 8, 2012
@rentzsch
Owner
rentzsch commented Jan 8, 2012

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.

@robrix
robrix commented Jan 8, 2012
@robrix
robrix commented Jan 8, 2012
@JoeOsborn

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.

@robrix
robrix commented Jan 9, 2012
@rentzsch
Owner
rentzsch commented Jan 9, 2012

@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
Something went wrong with that request. Please try again.