Considering removing constructor params for imported contracts. (Reverting #16)
Why
- It is not a natural or common use-case to be importing contracts that require constructor params. Or am I mistaken?
- The implementation is overly complicated, requiring building of graphs for a feature that is either very hardly used, or is an anti-pattern of
importuse.
Any comments? @Antanukas @graup
https://github.com/uzyn/solc-loader/pull/2 is a good one though and does not need #16 to work.
This feature is needed, at least for me. #16 is about library linking. If you use a library in the code (e.g. like this), after deployment the library contract addresses have to be put into be main contract.
Without this code people cannot deploy contracts that use libraries, as far as I understand.
@graup solc should have done the address linking automagically if I'm not mistaken.
Will verify.
You are right @graup . Sorry for the misinformation. I was rather confused with inject_.
I, however, do not quite agree with the introduction of inject_ and am thinking about removing it for a couple of reasons:
- It is not standard Solidity.
- I cannot think of a use case for it. If a contract/library is external, you would need to the address hardcoded or configured somewhere; if a contract/library is part of your project, you can simply use Solidity's standard
import().
Any thoughts on this?