> On Feb 10, 2017, at 3:02 AM, Daryle Walker <dary...@mac.com> 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/Build/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 (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to