Use objc_setAssociatedObject instead of making XVimWindow as subview

[JugglerShu]

If things have not changed since I saw last about XVimWindow binding to its corresponding tab view it made the XVimWindow as subview of the tab view. XVimWindow is the view which is not shown and it can not be view but to obtaining the associated XVimWindow I made it as subview.

I found that they have objc_setAssociatedObject runtime function and this looks more clean way to bind a object to another object.

[tomlu]

That means XVimWindow will no longer be an NSTextVIew? That would be very nice, I fixed a bug only yesterday that was caused by this.

On Tue, May 1, 2012 at 2:42 PM, JugglerShu < reply@reply.github.com

wrote:

If thinks have not changed since I saw last about XVimWindow binding to its corresponding tab view it made the XVimWindow as subview of the tab view. XVimWindow is the view which is shown and it can not be view but to obtaining the associated XVimWindow I made it as subview.

I found that they have objc_setAssociatedObject runtime function and this looks more clean way to bind a object to another object.

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/189

[JugglerShu]

Yes. XVimWindow can be anything. You can bind any object to a target object by name (key). I haven't used it but it should work. And if we want to add any attribute to existing Xcode objects we can use this too. What we have to share is the name (key).

For example, we may be able to hold text selection range in DVTSourceTextView's assosiated objct. ( I do not know if this is good way to hold these values )

[tomlu]

I've used this function, it works fine as long as you are careful what kind of ownership you specify. For us I suspect retain is the right choice.

The key is generally a pointer to some static object, but of course the nicest way is to wrap that behind some accessor method so everyone doesn't have to know about the key.

On Tue, May 1, 2012 at 3:17 PM, JugglerShu < reply@reply.github.com

wrote:

Yes. XVimWindow can be anything. You can bind any object to a target object by name (key). I haven't used it but it should work. And if we want to add any attribute to existing Xcode objects we can use this too. What we have to share is the name (key).

For example, we may be able to hold text selection range in DVTSourceTextView's assosiated objct. ( I do not know if this is good way to hold these values )

---

Reply to this email directly or view it on GitHub: https://github.com/JugglerShu/XVim/issues/189#issuecomment-5433856

[DarkDust]

The key is simply a unique number, the pointer is never actually dereferenced. Apple came up with the idea of using pointers to static variables to guarantee that the value is unique within an application. See http://darkdust.net/writings/objective-c/attaching-objects