Vscode-extension-for-zowe: Using generics describe methods on the ZoweTree interface to implement similar function for each node type

[Colin-Stone]

For example: rename(node: T); will replace renameDataset, renameNode and potentially renameDatasetMember although this may be an alternative node interface. Job does not need this function

[Colin-Stone]

Generic function/commands that are applied by different views

It feels to me as if the only interfaces we should have would be related to commands as follows. They tend to be very similar which was why I like the generics pattern rename(node: T);

• addFavorite
• removeFavorite
• saveSearch
• removeSearch
• addSession
• removeSession
• refreshTreeProvider
• refreshNode
• open/edit
• perform Search/pattern/fullpath
• create (Folder, file)
• delete (Folder, file)
• attributes
• rename (Folder, file)
• copy
• paste
• reveal

dataset specific

• submitMember
• submitJCL

uss specific

• binary transfer
• text transfer
• copypath
• upload

job specific

• open spool
• download spool
• modify
• stop
• owner
• prefix
• command
• modify

[Colin-Stone]

It feels to me as if the only interfaces we should have would be related to commands as follows. They tend to be very similar which was why I like the generics pattern rename(node: T);

On the other hand we already have the separation between the views so maybe we would stick with specific interface methods for USS/Datasets/Jobs rather than have a generics style call that joins and then splits the logical flow?

renameUSSFavorite etc

[zFernand0]

I don't know what the right answer is here, but I'd like to share that it's possible to clean some duplication of code with the generics you suggested. And if there is a need to support specific behaviors (like renameUSSFavorite) we can certainly extend the generic in an overloaded signature faction.

// This is just an example. : )
rename<T extends UssNode>(node: T): Promise<string>;
rename<T extends DsNode>(node: T): Promise<string>;
rename(node) { 
  // shared-code: show the inputBox
  // type-specific: API calls
  // shared-code: error handling and logging
  // shared-code: Update tree view
  // shared-code: return promise<string>
}

[Colin-Stone]

I don't know what the right answer is here, but I'd like to share that it's possible to clean some duplication of code with the generics you suggested. And if there is a need to support specific behaviors (like renameUSSFavorite) we can certainly extend the generic in an overloaded signature faction.

Thanks Fernando. It feels like we're moving in the right direction. I too have been experimenting.

1. Define the set of nodes.

export type IZoweNodeType = IZoweDatasetTreeNode | IZoweUSSTreeNode | IZoweJobTreeNode;

1. The subsequent interface is defined like this:

rename(IZoweNodeType);

1. Referenced like this from extension.ts:

vscode.commands.registerCommand("zowe.renameDataSet", (node) => datasetProvider.rename(node));

1. Implemented in the DatasetTree (and USSTree):

   public async rename(node: IZoweDatasetTreeNode) {

2. And whilst experimenting I secured the default behavior for instance with renaming a Job which wouldn't be implemented

public async rename(node: IZoweNodeType) { this.log.debug("not implemented"); }

Lets have a chat as I would like to understand your example for overloading better. I think we have many alternatives and just need to decide which one is makes most sense to everyone.