Support for id Properties

[Adlai-Holler]

I'd like to use plank for generating models for use inside an app i.e. no JSON parsing, and it'd be great to be able to specify @property id myThing and @property UIColor *myColor.

Is anyone else interesting in this capability?

[rahul-malik]

I think there is value in having other concrete types like UIColor but I'd want to avoid having id as a type since we lose pretty much any safety or usage guarantees for that property.

[Adlai-Holler]

For example, I would like to use plank to generate objects for use in Texture, and sometimes these objects have a userInfo field that stores a plain id so that the user can attach arbitrary context info to something like a an image request. That would be one great use case for this.

[rahul-malik]

@Adlai-Holler - currently we offer things like serialization, copying support for all properties, how do you propose handling this in the case of id?

[rahul-malik]

Also what would the value of type be for this in the JSON schema?

[ay8s]

@Adlai-Holler @rahul-malik I think we'd likely make use of this in our composer rewrite

[Adlai-Holler]

For serialization, I think we could start with not serializing it. I don't know what the extensibility rules for JSON schema are, but maybe we could offer a hatch like, throwing this out there, "type": "$objc(id)"

The bigger question is whether plank is/should be suitable for generating non-serialized plain-old-NS-objects for use inside the app, or if it should be specialized for talking with a server.

Texture, for example, could make great use of a solid ObjC code generator.

[rahul-malik]

The main question for me is does it make sense to create types with properties of unknown types. I think id ends up reducing type-safety and could introduce more issues than it solves.

The only thing that is JSON / Server specific currently is the assumption that dictionaries always use NSString as the key type.

That said, I think there is probably value in having a way to have users declare type extensions outside of the ones listed in JSONSchema and it would be up to them to declare what the corresponding type is for each supported language they wish to generate.

[brurend]

What about treat those cases similar to how Plank deals with NSDate?

The JSON value could be "any" string and with format you would define what kind of class it should be.

This way the responsibility would be up to each developer and not to Plank itself.

[rahul-malik]

@Adlai-Holler - working on a proposal to allow custom type extensions making plank a whole lot more flexible. I’ll forward when I have something to review