I'm importing an interface with types that conflict with my base contract. Namely the Errors enum | Stellar Developers | Page 1

ebon flume Sep 27, 2024, 1:04 AM

#

I've created an interface for a contract including it's contract structure as well as all its custom types. I'm making use of that interface both in it's own contract as well as importing it in an entirely separate contract. In the separate contract I have an Errors enum which is conflicting with the Errors enum from the imported interface even though I don't explicitly import or use those Errors in the separate contract.

I believe this has something to do with the interface exporting the types. Is there a way to rename or exclude types that aren't used in this separate contract so only the few types and interface I'm importing actually get built into the final wasm interface?

#

For reference it's basically this example
https://github.com/stellar/soroban-examples/tree/main/workspace
Just imagine the contract_a_interface also had a custom type and contract_b also had a custom type of the same name

ebon flume Sep 27, 2024, 1:55 AM

#

My solution right now is to set the error type and all the custom types to contracterror(export = false) and then in all the contracts I'm importing the interface I'm cloning the types file and removing the export = false bit. It works but it's obviously very fragile. Would be really nice if there was a way to more carefully select how to treat imported interface crate exports. Both for resolving name conflicts but also just to toss interface items a contract doesn't need

zinc pendant Sep 27, 2024, 2:17 AM

#

I take it the custom types are shaped differently? Is there a way to make a trait that extends both types.

But what about having an intermediary file that re-exports just what you need

pub mod contract_a_types {
    pub use contract_a::{Errors as ContractAErrors, OtherType};
}

pub mod contract_b_types {
    pub use contract_b::{Errors as ContractBErrors, AnotherType};
}```

Hmm or cant you use type aliasing like

#

use contract_b::Errors as ContractBErrors;```

#

Or use a makefile to automate that issue might work too

#

Something similar to an autogen.sh

#

I feel like there is some way you could make a third interface that both are a partial trait of im not sure how to do that in rust tho

#

Im guessing both enums have the same name and some of the same values when u said conflict is it feasible to just unify them or build around the conflicts on the new contract that intrgrates the other

#

I think someone said theres a problem with aliases though

#I'm importing an interface with types that conflict with my base contract. Namely the Errors enum