Context menu method signatures in delegate protocols for CPTableView and CPOutlineView

[david.ri...@enquora.com]

While looking at some old experimental code that implemented a context (right-click) menu in a CPTableView, I noticed some odd things in the delegate protocols for CPTableView and CPOutlineView:

• CPTableViewDelegate declares a method signature tableViewMenuForTableColumn:row: but the source files contains references to tableView:menuForTableColumn:row:
• CPOutlineViewDelegate declares the method signature outlineView:menuForTableColumn:row: but has no reference to outlineViewMenuForTableColumn:row:
• I can find no mention of either method signature in Apple's Cocoa documentation - going back to 10.9

Can anyone with a long memory save me from spending a day bisecting the git repo and recall the genesis of these methods?

More importantly (since I'm about to implement an approach that will work in Objective-C also, and to discard this one):

• It seems the delegate protocols for CPTableView and CPOutlineView should at least be consistent. If the contextual menu methods are unique to the Objective-J API, does not the tableViewMenuForTableColumn:row: make more sense and follow Apple's more recent pattern - a tableColumn always knows what table it belongs to?
• What is our policy, if any, on deprecation warnings when performing cleanup of this sort? Two major releases?
• Is our goal to maintain API correspondence with the current Objective-C API (and I believe it should be, with the obvious exceptions where platform constraints dictate otherwise)?
• Does anyone know of a way to directly download non-current Apple docsets (without installing older versions of Xcode)?
• The current CPTableView.j is 6,500 lines long. Has a conscious decision been made, one way or another, concerning single file size?

As always, have I missed something obvious or mis-understood this?

cheers,

d.r.

[Keary Suska]

> On Oct 13, 2016, at 4:59 PM, david.ri...@enquora.com wrote:
>
> While looking at some old experimental code that implemented a context (right-click) menu in a CPTableView, I noticed some odd things in the delegate protocols for CPTableView and CPOutlineView:
> • CPTableViewDelegate declares a method signature tableViewMenuForTableColumn:row: but the source files contains references to tableView:menuForTableColumn:row:

This is definitely a bug, or more like a typo, since the implementation is consistent but always uses -tableView:menuForTableColumn:row:. The easy fix is simply to change the method signature so implementors don’t get confused. AFAIK, Objective-J doesn’t do any protocol validation so the declarations are really just for documentary purposes.

> • CPOutlineViewDelegate declares the method signature outlineView:menuForTableColumn:row: but has no reference to outlineViewMenuForTableColumn:row:

Hmm—my version does not. It does *implement* this method, but mine only declares -outlineView:menuForTableColumn:item: (latest master).

> • I can find no mention of either method signature in Apple's Cocoa documentation - going back to 10.9

> Can anyone with a long memory save me from spending a day bisecting the git repo and recall the genesis of these methods?

I don’t recall any such methods, and my understanding that the canonical approach has always been to set the "menu” outlet (or call -setMenu:). I think this is a Cappuccino-specific feature.

> More importantly (since I'm about to implement an approach that will work in Objective-C also, and to discard this one):
> • It seems the delegate protocols for CPTableView and CPOutlineView should at least be consistent. If the contextual menu methods are unique to the Objective-J API, does not the tableViewMenuForTableColumn:row: make more sense and follow Apple's more recent pattern - a tableColumn always knows what table it belongs to?

I am not sure what that pattern is that you mention, but I haven’t seen it at least on OS X/Objective-C. To me it makes more sense to keep it consistent with the rest of the methods, and clearly the author of the bug had some confusion over this as well ;-)

> • What is our policy, if any, on deprecation warnings when performing cleanup of this sort? Two major releases?

> • Is our goal to maintain API correspondence with the current Objective-C API (and I believe it should be, with the obvious exceptions where platform constraints dictate otherwise)?

I second keeping it consistent. It is nice to have Cappuccino -specific features but minimally full parity is preferable.

> • Does anyone know of a way to directly download non-current Apple docsets (without installing older versions of Xcode)?

Even if you download Xcode, Apple hasn’t included docs as part of the install for some time now. I believe that Dash keeps archived docsets, so that it likely your best bet.

> • The current CPTableView.j is 6,500 lines long. Has a conscious decision been made, one way or another, concerning single file size?

I haven’t had a chance to do real-life evaluations but last I heard doing real-time compression/decompression is the best bet for performance and will eliminate most “size” issues, I imagine. Also, fewer bigger files are usually more performant than many smaller files, so I would lean in the opposite direction. Though file consolidation would not be useful unless there are some front-loaded compiler optimizations to eliminate unused code.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

[Martin Carlberg]

Hi!

Yeah, this is a bug.

Our goal is as you both say to maintain API correspondence with the current Objective-C API. There are exceptions of course.

The source file CPTableView.j is very long. When you build a Cappuccino application everything will be concatenated together to one or more larger files so I don’t see any problems with it. Except maybe from a human developers perspective of getting lost in a large source file :-)

The Objective-J compiler do protocol validation just like the Objective-C compiler. But all the methods are optional as it is a delegate protocol. So you can say the declarations are really just for documentary purposes. This is the same in the Objective-C world.

Best regards,

- Martin

--
You received this message because you are subscribed to the Google Groups "Cappuccino & Objective-J" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objectivej+...@googlegroups.com.
To post to this group, send email to objec...@googlegroups.com.
Visit this group at https://groups.google.com/group/objectivej.
For more options, visit https://groups.google.com/d/optout.

[david.ri...@enquora.com]

Except maybe from a human developers perspective of getting lost in a large source file :-)

This is the reason for my observation.

The source code for some class implementations is already spread across multiple files in independent folders/directories.

I have a number of Cappuccino source code fixes and cleanups on my to-do list and was wondering if any specific guidelines have ever been established for maximum LOC/file.

d.r. 

[Martin Carlberg]

To my knowledge there are no guidelines for maximum LOC / file.

- Martin