Support for id Properties about plank HOT 9 OPEN

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.

from plank.

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.

from plank.

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.

from plank.

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

from plank.

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

from plank.

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

from plank.

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.

from plank.

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.

from plank.

@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

from plank.