Re: Optionality in a NSManagedObject sub-class
Re: Optionality in a NSManagedObject sub-class
- Subject: Re: Optionality in a NSManagedObject sub-class
- From: Daryle Walker <email@hidden>
- Date: Sat, 11 Feb 2017 01:52:09 -0500
> On Feb 10, 2017, at 3:02 AM, Daryle Walker <email@hidden> wrote:
>
> It’s simple:
>
> - I’m writing this framework for an app, both macOS, with Swift 3 and Xcode 8.
> - My protocol has two non-optional strings.
> - I unchecked “Optional” for those attributes when editing the model file.
> - I used “Manual/None” for generation, then used the menu command to create the declaration and properties-extension files anyway.
> - The class uses “String?”, i.e. optionals, for my attributes.
> - This keeps the managed-object sub-class from matching the protocol when I add it from another extension (in a new file).
>
> The properties are mandatory. So is it OK to change the generated versions to non-optionals? What’s the risk/trade-offs if I do so?
I gave up and used an adaptor:
> extension RawHeaderField {
> /// Adapter for core properties to conform to InternetMessageHeaderField, since CoreData prefers to properties to be optionals.
> public class FieldAdapter: NSObject, InternetMessageHeaderMutableField {
> private var source: RawHeaderField
> public dynamic var name: String {
> get { return source.name ?? “" }
> set { source.name = newValue }
> }
> public dynamic var body: String {
> get { return source.body ?? “" }
> set { source.body = newValue }
> }
>
> init(source: RawHeaderField) {
> self.source = source
> }
> }
>
> /// A level of redirection since `RawHeaderField` can't directly conform to `InternetMessageHeaderField`.
> public dynamic var field: FieldAdapter {
> return FieldAdapter(source: self)
> }
> }
Hmm, I had to add that since just taking out the “?” suffixes caused a weird link error. I removed them again to show all of you the error, but the framework compiled/linked successfully.
…
I commented out the “field” declaration to make sure that wasn’t “fixing” my original problem, but it still didn’t come back. There was some sort of link error over the (direct) “name” and “body” properties, and suggested using the “-v” on the linker. But I can’t reproduce it now. Maybe it was a first-time making the objects error.
…
Nope, running “Clean” and re-compiling/linking/testing didn’t bring the error back. I’ll respond if it happens later.
…
Oh, I forgot to copy the protocol declaration back to the extension on the first line. That brought the error back:
> Ld /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Products/Debug/InternetMessages.framework/Versions/A/InternetMessages normal x86_64
> cd /Users/daryle/Documents/Repositories/XNW/XNW
> export MACOSX_DEPLOYMENT_TARGET=10.12
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch x86_64 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk -L/Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Products/Debug -F/Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Products/Debug -filelist /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Intermediates/XNW.build/Debug/InternetMessages.build/Objects-normal/x86_64/InternetMessages.LinkFileList -install_name @rpath/InternetMessages.framework/Versions/A/InternetMessages -Xlinker -rpath -Xlinker @executable_path/../Frameworks -Xlinker -rpath -Xlinker @loader_path/Frameworks -mmacosx-version-min=10.12 -Xlinker -object_path_lto -Xlinker /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Intermediates/XNW.build/Debug/InternetMessages.build/Objects-normal/x86_64/InternetMessages_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -fobjc-link-runtime -fprofile-instr-generate -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx -Xlinker -add_ast_path -Xlinker /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Intermediates/XNW.build/Debug/InternetMessages.build/Objects-normal/x86_64/InternetMessages.swiftmodule -single_module -compatibility_version 1 -current_version 1 -Xlinker -dependency_info -Xlinker /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Build/Intermediates/CodeCoverage/Intermediates/XNW.build/Debug/InternetMessages.build/Objects-normal/x86_64/InternetMessages_dependency_info.dat -o /Users/daryle/Library/Developer/Xcode/DerivedData/XNW-erfebwrlefqdajcsjohyazbstkyo/Bui
ld/Intermediates/CodeCoverage/Products/Debug/InternetMessages.framework/Versions/A/InternetMessages
>
> Undefined symbols for architecture x86_64:
> "InternetMessages.RawHeaderField.body.materializeForSet : Swift.String", referenced from:
> protocol witness for InternetMessages.InternetMessageHeaderMutableField.body.materializeForSet : Swift.String in conformance InternetMessages.RawHeaderField : InternetMessages.InternetMessageHeaderMutableField in InternetMessages in RawHeaderField.o
> "InternetMessages.RawHeaderField.name.materializeForSet : Swift.String", referenced from:
> protocol witness for InternetMessages.InternetMessageHeaderMutableField.name.materializeForSet : Swift.String in conformance InternetMessages.RawHeaderField : InternetMessages.InternetMessageHeaderMutableField in InternetMessages in RawHeaderField.o
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see invocation)
It seems like changing the “String?” to “String” made the properties fit the protocol on the surface, but there was something still incompatible.
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden