[swift-corelibs-dev] NSCoding methods
phausler at apple.com
Mon Dec 28 10:01:57 CST 2015
> On Dec 28, 2015, at 5:01 AM, Luke Howard via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
>> On 27 Dec 2015, at 9:31 PM, Luke Howard via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
>> I’ve implemented but not extensively tested decodeValueOfObjCType(). Do we need to support NSConcreteValue?
> I started looking at NSConcreteValue (commit 1a9fe560) and decoding it is fine (notwithstanding implementing all the special cases).
> What’s the plan for instantiating concrete of NSValue though?
> * Class clusters seem impossible to implement in Swift
Yep, there are a few things in the evolution list to propose this.
> * Factory methods are an API change
We need factory init methods to make this work which is not yet supported by the language.
> * NSValue becoming concrete seems to muck up CF bridging (also, fragile base class problem)
It will end up being a real rats nest to even get it close to working. In the end we will have two choices if we don’t have factory init methods, we can have NSValue or have NSNumber. My guess is that NSNumber is more commonly used in swift than NSValue.
> * I looked a little into using ManagedBuffer to size instances dynamically but it’s not much help by the time init() is called
If need be somethings can be dropped out to C as well
> * A lookaside table works and is straightforward to implement, but is pretty ugly
Not certain what you mean there; each NSValue is just a identity of a key in a dictionary to a NSConcreteValue that the methods forward to? That would mean that each method call would be a dictionary lookup… that does not sound scalable from a performance standpoint.
> — Luke
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
In summary - I think perhaps it would be better to start thinking about batching up parts of the NSCoder work and getting it merged before tackling NSValue
More information about the swift-corelibs-dev