1. Home
  2. Training Library
  3. Programming
  4. Programming Courses
  5. Smart Contract Development with Solidity

View/Pure Functions

Start course
Overview
Difficulty
Intermediate
Duration
3h
Students
49
Ratings
5/5
starstarstarstarstar
Description

This course provides a deep dive into the Solidity programming language which is used to implement smart contracts on blockchain platforms. This course will give you a practical understanding of Solidity and how to develop your own smart contracts.

Transcript

In the previous lectures, we were talking about the race, mapping, and structs, and in this lecture, we are talking about view and pure functions. They have not much in common with the previous lectures, I just want to highlight a few parts because we have worked with view and pure functions before. But I think I have not done a really good job in explaining what they exactly do, so this lecture is all about view and pure functions. What are view and pure functions? We have three types of functions in solidity. The ones are writing to a state variable, which we don't have yet, and then if you want to read something from a state variable, that would be a view function. And if you have a function which is only, for example, multiplying something and not accessing the state at all, then this would be a pure function. Let me give you an example of how that would work. And let's just assume we have an unsigned integer myUint and that is five. And now I'm going to give you free functions, one is a writing and two reading functions, whereas one is a pure function and one is a view function. So, the obvious one, we want to write, we want to update a state variable. It's sometimes also called a verified function, which needs a verification by a miner note is a writing function. So, we have a function called updateMyUint, and we have another argument here. And this is going to be a public function and this is going to write the argument to the variable myUint here in our state variable definition. Right. If you're going to run this, deployed a smart contract and I update this, obviously, I didn't make myUint public, so I cannot read this function now, so I need a reading function. In order to make a reading function, I have two versions, again, the one is just making this variable public. That would give me a get to function but as I said before, I actually do not want to do this, I want to have more control over my get to function, it's also easier to read in my source code, so I'm just going to make a function getMyUint, and this is a public view function and this returns as an unsigned integer namely our  [Author Typing]  return namely our Uint. All right. If I deploy this smart contract now, then I can getMyUint, I can update myUint, and I get this result back. So, all is good and fine. Again, coming back to these two functions, the one is called a verified function or a writing function, and the other one is also sometimes just called a local function or a read only function. Where does this come from? If I write anything to a smart contract, then I sent off a transaction into the network and that transaction needs to be mined, and as soon as the miner includes the transaction in a block, then the block is sent across to all other notes in the network, in the Blockchain. All other participating notes received that block, open that block, and they are going to execute the same transaction again. Now, they're not just execute the transaction, they are going to verify if the transaction adds up. Now, we have transaction signature which is generated from the private key of the account that is sending the transaction, and we have the account or in other words, we have access to the public key of the private key which only the person has. So, we have a private key which everybody has, we have the signature, which is attached to a transaction, and we have a private key which generated the signature that only the person has, which is signing the transaction. Now, these three things with the public key, we can verify the signature of the transaction and everybody is doing that. So, by sending around a block from a miner note, not only the block is verified, but also internally, each and every transaction is verified. Each and every transaction is again run on every participating note, eating up some CPU time, some resources, and for that you pay a little bit of gas to the miner and to the network in form of this gas fee which we are going to discuss a little bit later. But also in every participating note, if the transaction is run again which is updating this MyUint from five to 10 which I did here, then every participating note has a new state, and this is where this state variables, this storage variables come in. They are saved in every database on every participating note, and the notes have to run the transactions in order to get to the updated state. Now, this is where these verified transactions or this writing transactions come in. Now, every participating note has a copy of that ledger, has a copy of the Blockchain or the database in their own disk, ideally. So, in order to read from the state, you don't have to send this somewhere, you can't just open your local copy of the database and read out that variable. So, this is why a view function is also sometimes called a local function, only accessing the local database. So, this one makes the promise that whoever is interacting with your smart contract that it's not updating the state. If we would write here something to our variable, myUint is 11, then we would immediately get an error telling us that the function is declared as a view function, and this expression potentially modifies the state, and therefore you cannot have a view function here. Okay. So, having this in mind, we can also reason hopefully properly that writing function can access a reading function without any problems, but reading function cannot access the writing function because once you make the promise that you're not reading, that you're only reading from state, you cannot write anymore to that. So, this one would not work, updateMyUint. That doesn't work either because we have a view function and that one potentially modifies the state. Okay. This is view and non-view functions. Now, we have a third one which is a pure function, and our pure function cannot read or write from the state. So, I'm going to show you what is a pure function, multiply by five, and we have an unsigned integer, some number as a public pure function, and returns Uint. And here, we are going to return some number times five. Now, in our pure function, we make the promise to whoever is going to interact with our smart contract that we are not going to access any state variables at all. So, this is a self-enclosed function where everything that is running this function is only in the scope inside the function, including its arguments. Pure functions, as you might can reason now, they cannot access any view functions because view functions access the state, and they just made a promise that they are not going to access the state. And pure functions can also not access any of the writing functions because if you don't want to access the state, you cannot read or write to the state, and thus you cannot update this unsigned integer or any storage variables at all. On the other hand, pure functions can access other pure functions, because you don't access the state just by accessing another pure function. Well, that works fine. View functions can access pure functions because they can read from state, or they can read from anywhere, they just cannot write anywhere. And writing functions can access both view and pure functions. So, that should be hopefully fairly clear by now. Now, the last one, the last thing for our lecture here is obviously a short coding challenge, and the coding challenge this time, it's fairly easy. We want to have a function, I'm not going to tell you if it's a view or a pure function, you've got to find out yourself. We want to have a function which is returning us the MyUint times five, when we click the button, so it doesn't have any arguments. It's just, I'm going to write this down for you, function five times myUint, and this is a public and maybe a view or a pure on neither of them function that returns a Uint. And here we want to multiply the myUint using the multiply by five function and return it as a non and integer. So, if you want to do this coding challenge, then pause the video now. If not, just let it run, and I'll show you in a second how it's done. All right. I hope it's not too hard. Now, here we obviously have a view function because we are going to access the state variable, and we are going to return multiply by five myUint, and that should give us in our initial state 25. And here it is. All right. There's pretty much everything there is to say about view and pure functions in the Solidity version 0414, we have this view and pure functions and Solidity version 050, it's mandatory to use them. Before that they were called constant functions, so there was no view and no pure keyword. They were all called constant functions, and then they split it up into some more fine granular promises towards the interface if they access the state or not, and I personally think it's a little bit better. And that's it for this lecture, and in the next one we are talking about the concept of time. We're talking about how we can use timestamps and how we can figure out if we have maybe a running period for a building contract and auction contract, where we have several days where somebody can buy something or several hours, and that's going to be the content of the next lecture. I'll see you there.

 

About the Author
Students
58
Courses
7

Tom is a CTO, senior back-end developer, and systems architect with over twenty years of hands-on development experience in a variety of languages and systems. He has a CS master's degree and has been working with Ethereum and blockchain technologies since 2016.

Covered Topics