You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for sharing this wonderful code! I had been thinking about the problem 'how to use a modern struct with ancient cocoa objects like NSOutlineView?' before. Your demo is great!
Looking at the code, I was asking myself: would it not be moer convenient to 1) define TreeNode and TreeList as a protocol instead of a struct and while doing so 2) make sure the implementation is Identifiable?
My thinking is that that might simplify some use cases: a user could make its struct (S) directly conform to the protocol (i.e. make sure it has id and children variables), thus not having to access it as a stored value + extra complexity in case S already stores children?
For example: suppose one has a Directory struct that (already) has a fetch method to fetch directory content from the filesystem. Also, that Directory would already store the list of children in a set or array [to prevent having to fetch large directories over and over again). In your demo, the Directory would have to be stored as a value inside the TreeNode/TreeList. In my thinking it would be more logical to make the Directory conform to TreeNode, without further ado. This would be simpler than having to sync the TreeNode's children with the children already stored in the Directory. Or am I missing something here?
I would love to hear your thoughts on this.
Thanks again, and keep up the good work. Much appreciated!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi David,
Thanks for sharing this wonderful code! I had been thinking about the problem 'how to use a modern struct with ancient cocoa objects like NSOutlineView?' before. Your demo is great!
Looking at the code, I was asking myself: would it not be moer convenient to 1) define TreeNode and TreeList as a protocol instead of a struct and while doing so 2) make sure the implementation is Identifiable?
My thinking is that that might simplify some use cases: a user could make its struct (S) directly conform to the protocol (i.e. make sure it has id and children variables), thus not having to access it as a stored value + extra complexity in case S already stores children?
For example: suppose one has a Directory struct that (already) has a fetch method to fetch directory content from the filesystem. Also, that Directory would already store the list of children in a set or array [to prevent having to fetch large directories over and over again). In your demo, the Directory would have to be stored as a value inside the TreeNode/TreeList. In my thinking it would be more logical to make the Directory conform to TreeNode, without further ado. This would be simpler than having to sync the TreeNode's children with the children already stored in the Directory. Or am I missing something here?
I would love to hear your thoughts on this.
Thanks again, and keep up the good work. Much appreciated!
Hans
Beta Was this translation helpful? Give feedback.
All reactions