Module model

[perama-v]

I am thinking there might be two ways to extend a contract, e.g., an ERC token to be Ownable.

1. A myToken.cairo with top-of-file import-style mechanism: from ozcc import ERC, Ownable.
2. A generator CLI program: ozcc generate ERC Ownable that produces a populated myToken.cairo.

Option 1 would mimic existing Solidity experience, and would involve functions overriding others in a hierarchy.

Option 2 would involve the program fetching only non-overridden functions from the chosen combination and placing those in a file.

Both options are compatible with pre-generated common patterns (721, 721-ownable, 721-ownable-enumerable, 721-enumerable). Option 2 might result in a less-complex contract file, because there would be no override patterns for the developer to mentally manage.

[perama-v]

One mechanism for option 2 could be:

Each function has a specially formatted comment above the function:

ERC20.cairo:

##--## overwritten_by: Ownable/xyz
@external
func xyz():
    # abcd
    return ()
end

Ownable.cairo:

@external
func xyz():
    # cdef
    return ()
end

When the contract is pieced together from two different files, this comment could be used to select only one of them.

[perama-v]

The resulting myToken.cairo would then contain:

all_builtins_here

all_imports_here

all_storage_here

### Custom MyToken logic ###
@external
func mintMyToken{
        pre_populated_pointers_here
    }(
        number_to_mint : felt
    ):
    only_owner()
    _mint(number_to_mint)
    return ()
end

# Custom function 2 here

### End of custom section ###

### Standardised token logic ###
@external
func xyz():
    # cdef
    return ()
end

remaining_standardised_functions_here

(The xyz function containing #abcd does not appear in the file)

[frangio]

Option 1 would mimic existing Solidity experience, and would involve functions overriding others in a hierarchy.

I would really discourage anything resembling inheritance and overrides. Instead, I think the language should try to develop a composition-based approach.

Importing works fine when you just need to "re-export" the external functions. It breaks down when you need to modify the behavior for some of those external functions, or to hide them. For those situations I would like to see a way to import modules for internal use, without re-exporting all of the external functions. Then using the internal interface you can define the functionality that you actualy want to export.

[fracek]

I agree with this. I mentioned on Discord that I'd like to see from my_other_module export external_function but they pointed out that with that it's not possible to use isort to automatically sort Cairo imports.

Another way would be for import to strip any external or view attributes, if developers wants to re export the function they can something like:

from my_other_module import external_function

external(external_function)

@external
func something_else():
  return ()
end

I think it's also consistent with @external being a decorator.

Composition of storage variables I think it's more difficult to solve and would require bigger changes to the language.