0.1070 s - время 151 - запросов

We use cookies in order to improve your experience while using our website. If you continue to use our site, you accept our Cookies Policy, revised Privacy Policy and updated Terms of Use.

BTC $ 4018.53318252 (-0.35 %)
ETH $ 138.964050326 (-1.09 %)
XRP $ 0.3163865787 (-0.37 %)
LTC $ 59.7580404764 (-2.88 %)
EOS $ 3.7351718518 (-1.37 %)
BCH $ 162.435168518 (4.16 %)
BNB $ 15.5219827801 (-2.37 %)
XLM $ 0.1127246048 (3.33 %)
USDT $ 1.0088246146 (-0.24 %)
TRX $ 0.022846409 (-1.56 %)

Update Of Solidity Language: Function Visibility Issues

19:00 16/12/2018
Update Of Solidity Language

Introduction

 

The Ethereum project is famous and popular in the crypto ecosystem for several reasons. First, it proposes a flexible and convenient way to develop new projects. Most of crypto ICOs are implemented on the Ethereum blockchain. Second, it has a solid background for the Ethereum Virtual Machine and languages addressing it. In general, Ethereum is independently developed software using a programming language called Solidity designed to target its specific virtual machine.

 

As any other software, solutions within the Ethereum system require upgrades. It is especially important for the Solidity language, as it still hasn’t reached the version 1. The latest update changes the current version number to 0.5.0. This index may be considered as a milestone, so let’s pay attention and examine the update in detail.

 

General information on the update

 

All details on the update can be found in several sources. Let’s consider two of them. The first one is the Solidity changelog page at GitHub. It does not contain explanations on each change. However, the list is the most complete, it shows changes starting from July 2015, and includes the following categories:

 

  • Breaking changes;
  • Necessary code updates;
  • Language features;
  • Compiler features;
  • Fixed bugs.

 

Another source is the Solidity manual page provided by the “Read the Docs” website. It explains the most important changes and contains examples and the code. It holds the following categories:

 

  • Semantic changes;
  • Semantic and syntax changes;
  • Explicitness requirements;
  • Deprecation section;
  • Issues of contracts interoperability.

 

Here, we will examine only one important change.

 

Functions visibility

 

The first change explained in the log is about functions visibility. Each function inside of a smart contract is visible for other on-chain functions in different ways — and it is not about the real visibility for developers or external observers. Any blockchain holder will see all functions and their details. It’s rather about the ability to interact with a function.

 

Let’s consider a contract with a function called function_name(). There are four types of visibility: external, public, internal, and private. They may be applied both to functions and state variables. The only restriction is that state variables can’t be external. Hereafter, we will talk about functions visibility.

 

Internal

 

The simplest type of functions has the “Internal” visibility. It means that only other contract’s functions can address this one. Also, if our contract_1 becomes a raw model for inherited contract_2, this function will be copied as it is.

Internal function call
Internal function call

 

Private

 

Functions defined as “Private” have the same properties as “Internal” ones, but they will not be copied to the inheriting contract. This type of functions belongs exclusively to the contract that holds them.

Functions inheritance
Functions inheritance

 

Public

 

Functions defined as “Public” have an extended visibility compared to the Internal ones. In general, the list of contract’s functions available from outside of the contract is called “interface”. It represents the means for contracts interaction. External contracts can call for the “Public” functions execution as well as the hosting contract by itself. The hosting contract requires no special syntax to call the function.

Public function call
Public function call

External

 

Functions defined as “External” are available for all contracts on blockchain with some peculiarities. “External” functions can be addressed by all of contracts in a similar syntax. It means that hosting contract can’t just call a function by its name. It must use the this.function_name() syntax. “External” functions are similar to “Public” ones but some issues related to the data processing efficiency require using them.

External function call
External function call

 

Visibility overall changes

 

In the previous Solidity version, any function created without visibility specification was automatically assigned “Public”. This has changed with the 0.5.0 update. Explicit function visibility is now mandatory. All functions and interfaces must have a specified visibility definition before being published on blockchain.

 

This doesn’t mean that previously compiled contracts will be abandoned. According to the developers, there will be no problems with interacting with contracts that already exist on-chain.

 

Afterword

 

The development process brings many interesting solutions, options and proposals. Examining the changelog, we can find some interesting tendencies and opinions in developers’ decisions. However, their volume is so big that, unfortunately, we can’t cover them all at once. In our next article, we will examine more interesting changes in Solidity.

Found a mistake? Highlight it and press Ctrl + Enter to notify the administrator.

Up-to-date Blockchain and cryptocurrency news. Be the first to know!

What is it for?