progrium/darwinkit

NSNib issues

Closed this issue · 3 comments

firelizzard18 commented

I have some issues with the NSNib interface. My preferred solution would be API-breaking, which may be OK because the project is still pre-v1:

  • NSNib_Init - This uses a specific init method, so IMO it should be named something like NSNib_InitWithName
  • I'd like to add a wrapper for init from NSData, e.g. NSNib_InitWithData
  • InstantiateWithOwner discards the return value. instantiateNibWithOwner:topLevelObjects: can return false - that should be passed to the caller as a boolean.
  • instantiateNibWithOwner:topLevelObjects: is deprecated in favor of instantiateWithOwner:topLevelObjects:. The difference is that the latter requires the caller to retain any objects they are interested in. If I understand correctly, retaining a reference to the nib, the array, or a given object is sufficient to keep the object from being deallocated.

I'm happy to open a PR with these changes.

The readme says "1:1 mapping of API names with Objective-C APIs", and it sounds like the eventual goal is to use a generator. In that case, shouldn't the Go function names match the Objective-C method names?

progrium commented

yea in some cases there is just a bare *_Init() from trying out conventions that might work for code generation, but in this case it might not map to anything real or useful or conventional. I don't think any of your suggestion is API breaking? PR away, just document any new kinds of translations to Go in the API so we can be sure to work them into generation.

firelizzard18 commented

Renaming NSNib_Init to NSNib_InitWithName would be a backwards-incompatible change, as would be adding a return value to (*NSNib).InstantiateWithOwner, as it changes the method signature.

PR away, just document any new kinds of translations to Go in the API so we can be sure to work them into generation.

I'm not sure what you mean. I was planning on making changes in cocoa/NSNib.go.

progrium commented

My first thought if you wanted to not make breaking changes would be not to change NSNib_Init but just add NSNib_InitWithName, so I assumed you could just do that. Regardless, not concerned about making breaking changes right now. There are versioned releases and it's pre-1.0. Especially if it's making it more in line with the actual Cocoa APIs.

Re documenting, all I'm saying is if you end up changing the API to be more helpful in Go, to point that out and discuss. Like for example at some point we decided to try to return strings instead of NSString pointers. That way we can work those conventions into the code generation. Tell me if I can be more clear.