As IVotes is a interface and cannot be deployed.
IVotes public immutable token;
constructor(IVotes tokenAddress) {
token = tokenAddress;
}
....
Error: *** Deployment Failed ***
"IVotes" is an abstract contract or an interface and cannot be deployed.
Import abstractions into the '.sol' file that uses them instead of deploying them separately.
Contracts that inherit an abstraction must implement all its method signatures exactly.
A contract that only implements part of an inherited abstraction is also considered abstract.
I want to use IVotes address passing in GovernorVotes constructor.
I tried bunch of methods but none works
The Solidity snippet, that you shared, expects a contract on the tokenAddress to implement the IVotes interface.
But it needs to be a "full" contract with all function bodies - not just the function declarations.
Related
I am learning solidity and got to know that interface and abstract are both classes that may contain unused functions.
My doubt is: What is the difference between interface and abstract contract in a solidity smart contract?
It's the same as in most other object-oriented programming languages:
Interface only declares functions. Cannot implement them.
Abstract class can declare functions (same as interface) as well as implement them.
Both cannot be instantiated and need to be implemented/inherited from.
Example:
interface IMyContract {
// can declare, cannot implement
function foo() external returns (bool);
}
abstract contract MyContract {
// can declare
function foo() virtual external returns (bool);
// can implement
function hello() external pure returns (uint8) {
return 1;
}
}
Extensibility is key when building larger, more complex distributed applications. Solidity offers two ways to facilitate this:
Abstract Contract
Contracts are identified as abstract contracts if at least one of their functions lacks an implementation. This is the only requirement for abstract class. As a result, they cannot be compiled. They can however be used as base contracts from which other contracts can inherit from.
Unlike other languages, Solidity contracts do not need an abstract keyword to be marked as abstract. Rather, any contract that has at least one unimplemented function is treated as abstract in Solidity. An abstract contract can be neither compiled nor deployed unless it has an implementing contract
contract MyAbstractContract {
function myAbstractFunction() public pure returns (string);
}
if a contract inherits an abstract contract and does not implement all the unimplemented functions, then that contract will be considered abstract as well
//MyContract is also abstract
contract MyContract is MyAbstractContract {
function myAbstractFunction() public pure returns (string)
}
But this is not abstract because we are implementing the function.
contract MyContract is MyAbstractContract {
function myAbstractFunction() public pure returns (string)
{ return "string value to return"; }
}
An abstract contract can have both implemented and unimplemented functions.
Interfaces
interfaces can have only unimplemented functions. Also, they are neither compiled nor deployed. They are also called pure abstract contracts.
Interfaces cannot implement any of their functions. All interface functions are implicitly virtual
Interfaces are defined with the keyword Interface.
Interfaces cannot inherit other contracts or interfaces (after solidity 6.0.0 interfaces can inherit from interfaces) but other contracts can inherit from interfaces.
Interfaces cannot define a constructor
Functions of an interface can be only of type external.
Interfaces cannot have state variables
As of now Interfaces cannot define structs and enums but might change soon.
In Solidity we have four types of access. Two of them are private and internal.
What is the difference if both of them can be used inside smart contract and both of them are not visible after deploying?
Access types:
public - can be used when contract was deployed, can be used in inherited contract
external can be used when contract was deployed , can NOT be used in inherited contract
internal - can NOT be used when contract was deployed , can be used in inherited contract
private - can NOT be used when contract was deployed, can NOT be used in inherited contract
internal properties can be accessed from child contracts (but not from external contracts).
private properties can't be accessed even from child contracts.
pragma solidity ^0.8;
contract Parent {
bool internal internalProperty;
bool private privateProperty;
}
contract Child is Parent {
function foo() external {
// ok
internalProperty = true;
// error, not visible
privateProperty = true;
}
}
You can find more info in the docs section Visibility and Getters.
public: anyone can access the function
private: only this smart contract can call this function
internal: only this smart contract and smart contracts that inherit from it can call this function
external: anyone can access this function unless this smart contract
Note that external uses less gas than public so if the function is not used by your contract, prefer external over public.
More explanations in this article
I was digging into this OZ smart contract:
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Context.sol
As you may see, it has only two functions to deal with metatxs. I can't figure out why this contract is defined as abstract, as both functions are implemented. Thanks in advance to all of you!
The Context contract was made abstract in the pull request #2229. One of the contributors links to the issue #8162 for explanation:
it seems like what the keyword does is mark the contract as non-deployable (i.e. it needs to be inherited from). Because contracts missing function implementations are always non-deployable, they require abstract.
From my understanding, their reason was just to explicitly say "This contract has no use on its own, and should not be deployable (on its own)."
Currently reading solidity documentation:
https://solidity.readthedocs.io/en/develop/types.html#function-types
By default, function types are internal, so the internal keyword can
be omitted. In contrast, contract functions themselves are public by
default, only when used as the name of a type, the default is
internal.
This does not make sense to me. How can a function be internal and public at the same time?
I know internal means functions can only be called within the contract and external can be called outside of the contract. So to me, internal is private and external is public but the documentation makes it sound like it can be public and internal at the same time?
So what is the difference, if any, between internal/external and public/private in regards to functions?
Here is the difference between the four keywords:
private means it's only callable from other functions inside the contract
internal is like private but can also be called by contracts that inherit from the current one
external can only be called outside the contract
public can be called anywhere, both internally and externally.
In the terminology of Solidity internal/external also uses as description 'two kinds of function calls' and not only as access modifiers.
Take a look at the documentation section about 'Visibility and Getters' inside the contracts.
Since Solidity knows two kinds of function calls (internal ones that do not create an actual EVM call (also called a “message call”) and external ones that do), there are four types of visibilities for functions and state variables.
I am new to Objective C, I wanted to understand protocol concept more clearly.
#protocol protocolName
#optional
#required
#end
Can I correlate #optional part with virtual function and #required part with pure virtual function of C++?
Is #protocol is way of Objective-C to create interface and abstract class?
Is #protocol is way of Objective-C to create interface and abstract
class?
Exactly.
Can I correlate #optional part with virtual function and #required
part with pure virtual function of C++?
Yes you can but there is one difference - if classA does not implement OptionalProtocolMethodB, any attempt to call [classA OptionalProtocolMethodB] will cause a runtime exception. Calling a virtual function in C++ will not.
You should check if the class implements the optional method before calling it. Example:
if ([_delegate respondsToSelector:#selector(didUploadedTotalBytes: totalBytesExpectedToWrite:)]) {
[_delegate didUploadedTotalBytes:_uploadedBytes totalBytesExpectedToWrite:_totalBytes];
}
Forget about abstract classes in Objective-C (there are none). Forget about protocols in connection with class hierarchy.
A protocol describes a set of methods that an object needs to implement to be usable for some purposes. For example, if a protocol has two required methods "color" and "setColor", then any instance of any class implementing these two methods can be used. In addition, the class must claim that it supports the protocol - this avoids a class being used by coincidence. On the other hand, all methods in a protocol could be optional and a class could claim to support the protocol without implementing any of the methods.
There will usually be a description of what happens when optional methods are not implemented. For example, the documentation for an optional method returning BOOL might say "if not implemented, it is assumed that the method returns YES". In other cases the documentation might say under which circumstances an optional method will be called. In any case, the caller must check that an optional method is implemented before calling it using "respondsToSelector". (Of course, the documentation might say for example that if wantsComplexBehaviour returns YES, then doComplexBehaviour1 and doComplexThings2 must be implemented, and not implementing that would be a programmer error punished with an exception when the methods get called).
This is usually all done in a very pragmatic way. Many classes that you use need delegate objects which implement some protocol, so you either add the protocol methods to your implementation and make yourself the delegate, or you create a class for the sole purpose of creating these delegates and implement all the protocol methods in the implementation of that class.