Adds a nondestructive -attributeTypeName property to attributes

[robrix]

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

[robrix]

I should note, this would close #85.

[robrix]

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]

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]

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]

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]

As I mentioned, Class and id.

Rob Rix, Unknown Quantity.

On 2012-01-07, at 10:51 PM, Jonathan 'Wolf' Rentzsch [email protected] wrote:

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.

---

Reply to this email directly or view it on GitHub:
#86 (comment)

[rentzsch]

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]

That works for me.

[robrix]

Although of course, folks will have to edit their data models too, which is rather more tedious.

[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]

Yes, that would be a good approach. We still have to change the templates, but not all the data models.

[rentzsch]

@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;