Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add factory class #534

Merged

Conversation

Niraj-Kamdar
Copy link
Contributor

@Niraj-Kamdar Niraj-Kamdar marked this pull request as draft November 16, 2021 11:40
@dOrgJelli
Copy link
Member

TODO:

  • Add interface test to bind sanity test case. For example:
#import { Query } into Interface from "interface.eth"

type Query implements Interface_Query {
  ...
}
  • Merge the Interface_Query and Interface_Query_Factory classes. A rough example of what this might look like:
class Interface_Query {
  static interfaceUri: string = "/ens/interface.eth";
  
  constructor(public uri: string) { }

  method(args: Input_method): string {
    w3_subinvoke(this.uri, etc);
  }
}

@Niraj-Kamdar
Copy link
Contributor Author

From what I understand, we are going to use interfaces(InterfaceImplementedDefinition[]) property of QueryDefinition to see whether the imported namespace is interface or module, if it's imported and not in the interfaces it's a module and we won't be providing constructor for this and generating code for it like following so that user can directly use Ethereum_Query.method just like they've been doing.

class Ethereum_Query {
  static uri: string = "/ens/ethereum.eth";
  
  static method(args: Input_method): string {
    w3_subinvoke("/ens/ethereum.eth", etc);
  }
}

But in the case where it is in interfaces array, it will be interface and we will be generating code for this like:

class Interface_Query {
  static interfaceUri: string = "/ens/interface.eth";
  
  constructor(public uri: string) { }

  method(args: Input_method): string {
    w3_subinvoke(this.uri, etc);
  }
}

But doing it like this would require user to implement all the interfaces that he just want to use.
Ex: I have core polywrapper which uses token interface and for token interface there are USDC, DAI, and USDT
implementation polywrappers. From OOP perspective, there is only inheritance from token -> USDC, token -> DAI and token -> USDT. while we don't need to have token -> core inheritance but just need composition instead. So, I don't think it's a good idea to mark the core polywrapper as implementation of token interface polywrapper.

Let me know what do you think and whether I get it wrong.

@dOrgJelli dOrgJelli marked this pull request as ready for review November 22, 2021 20:21
@dOrgJelli dOrgJelli changed the base branch from prealpha to prealpha-dev November 22, 2021 21:21
@dOrgJelli
Copy link
Member

Made an issue here to describe some future changes we might want to make: #547

@dOrgJelli dOrgJelli merged commit 2059f60 into polywrap:prealpha-dev Nov 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement Interface_Query_Factory to create Interface_Query from any URI
2 participants