-
Hello I understand that we pass the address as a parameter in the AggregatorV3Interface, but when you look the interface all the function are empty (ok that's normal for an interface :) but how it can process and send a result if there'is nothing in the functions to use the parameter ? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
Hii @akugone ! I think its similar to #2129 you can take a look at this and if you have further doubt you can ask it 🙌 |
Beta Was this translation helpful? Give feedback.
-
Interfaces as the name suggest are only to get the idea of what actual contract looks like( i.e. what functions it has what are its input parameters etc. ). In your case AggregatorV3Interface priceFeed = AggregatorV3Interface(0x8A753747A1Fa494EC906cE90E9f37563A8AF630e); you specify that this priceFeed.version(); without even having the actual code for aggregator v3 contract, |
Beta Was this translation helpful? Give feedback.
-
"I understand that we pass the address as a parameter in the AggregatorV3Interface" Incorrect, that is type-casting. We are explicitly converting the address A simple example would be: string strNum = "1";
uint256 intNum = uint256(strNum); "but how it can process and send a result if there'is nothing in the functions to use the parameter" That is a characteristic of A simple example to interact with other contracts via contract Counter {
uint public count;
function increment() external {
count += 1;
}
}
interface ICounter {
function count() external view returns (uint);
function increment() external;
}
contract MyContract {
function incrementCounter(address _counter) external {
ICounter(_counter).increment();
}
function getCount(address _counter) external view returns (uint) {
return ICounter(_counter).count();
}
} |
Beta Was this translation helpful? Give feedback.
-
@akugone Hey! I think it is not clear to you, why are we using For using any contract in our contracts we required 2 things. 1. We have an address of the aggregator contract, the only thing that we required is ABI. Now 1 way is to just copy the whole implementation of the aggregator v3 contract into its separate file and use it in our contract by importing it, by doing so when you compile your contract it will generate the ABI of the aggregator contract and it will run fine. Now some contract implementations are too big and sometimes in multiple contracts, so we have an easy solution for it. Instead of coping the whole implementation of the contract, we can just copy the interface of the main contract, it will generate the same ABI for it. And openzeppelin and other similar contracts have made it very easy for us, they have created packages for us, so now we do not even need to copy the interface of the main contract, just do this with the above line. |
Beta Was this translation helpful? Give feedback.
"I understand that we pass the address as a parameter in the AggregatorV3Interface" Incorrect, that is type-casting. We are explicitly converting the address
0x8A753747A1Fa494EC906cE90E9f37563A8AF630e
to type AggregatorV3Interface, not passing as a parameter.A simple example would be:
"but how it can process and send a result if there'is nothing in the functions to use the parameter" That is a characteristic of
interface
(refer abstract contracts—primarily an OOP-concept).A simple example to interact with other contracts via
interface
(from Solidity):