Return to Operation Data

Return to Top

Pure methods are limited to are often referred to as Pure Functions. Pure Functions are a cornerstone in Functional Programming and are designed to produce no Side Effects. Pure Functions are characterized as follows¹⁾:

• Are dependent only on

  • Declared input parameters
  • Algorithm to implemented
  • Values within the scope of the function, therefore, it can not

    • Depend on accessing any values defined outside the function scope (i.e., another field in the same class, or global variables)
    • Modify mutable values outside the function scope (i.e., other fields in the same class, or global variables)
    • Use external input or output (I/O). It can’t rely on input from files, databases, web services, UIs, etc; it can’t produce output, such as writing to a file, database, or web service, writing to a screen, etc.
• Do not modify input parameters

Figure 1 provides a grapic represeting a Pure Function. Basically, the Pure FUnction is an isolated piece of logic that given the same input always produces the same output. It's isolation means it has no unintended sideeffects outside of itself and only the inputs determine the processing. Another way to think of a Pure Function is at their center there is a Deterministic Algorithm (Also see Black Box Testing).

Figure 1: Pure functions

In some languages (i.e., C, C++, Rust, PHP, JavaScript/ECMAScript), it is possible to have methods (i.e., procedures or functions) existing outside the class container. Java and C# requires operations to exist within a class container, and therefore does not support General Methods. C++ does not recommend having General Methods outside of a class, but because C++ is more or less an extension of C, it does support them.

Often, the architecture and design of Functional Programs depends on the identification, design and creation of pluggable, reusable functions. Many of the frameworks used in modern applications reaching across many tiers rely heavily on stateless, client-server Representational State Transfer (REST) models and Command Line Interfaces (CLIs) .

Figure 2: The use of pure Functions.

Return to Top

Ethereum's Solidity is an Object-Oriented Programming (OOP) supporting four closely related object container types (Java and C++ have just one class):

• contract
• interface
• library
• struct

does have support defining and using General Methods, those functions not directly pertaining to the Smart Contract, but can be used by the smart contracts but it does support being able to create libraries of reusable functions that support a way to provide operators for specific types.

Return to Top

Return to Top

As of Solidity 8.1, it is possible to defines a library. A library is a kind of contract, that has no Ethereum Storage associated with it and in addition, it cannot hold ether. One way to think bout a solidity library is as a Singleton in the Ethereum Virtual Machine (EVM). In other words, it is a piece of code callable from any contract without the need to redeploy it. ²⁾

Libraries in Solidity contracts are blocks of reusable code containing functions usable by other contracts on the blockchain network. When used correctly, libraries support modular, Object-Oriented Programming (OOP) designs.

The main advantage for using library is code reusability across multiple contracts preventing duplication of code and the reuse of testing snd documentstion of the code. In addition, libraries save on gas by not deploying the code multiple times on the blockchain.

Libraries are a special form of contracts with the following restrictions:

• Are singletons
• Not allowed any storage or state variables that change
• Cannot have fallback functions
• Have no event logs
• Do not hold ether
• Are stateless
• Cannot use destroy
• Cannot inherit or be inherited

Libraries allow for the addition of functionality to the basic types (i.e., uint) or complex user defined types (i.e., struct). Libraries are isolated from other blocks of code (i.e., contracts) that have no rely on the storage (i.e., state variables) from the calling contract and supplied to the functions.³⁾

Libraries support different Data Types:

• User defined strut
• User derinde enum
• User defined immutable variables (i.e., constant)

  Note: Library constants become part of the Bytecode rather than in storage (i.e., not as variables on the blockchain itself)

Return to Top

The following code provides examples for:

• Creates a library called StudentRecord (Line 4)
• Creates a user defined type (i.e., struct) defining a StudentRecord concept adding the following fields: (Lines 5-9)

  • name (Line 6)
  • studentNumber (Line 7)
  • totalClassPoints (Line 8)
• Defines a function named addPoints that accepts two parameters (Lines 11-17):

  • An instance of a StudentRecord in storage (Line 12)
  • The earnedPoints to add to the students record (Line 13)
  • The actual calculation of the students totalClassPoints (Line 16)
  • The end of the definition of addPoints function
• End of the definition of the library (Line 17)

pragma solidity ^0.8.1;
// SPDX-License-Identifier: MIT

library StudentLibrary
{ struct StudentRecord
    { string name;
      uint studentNumber;
      uint totalClassPoints;
    } // End StudentRecord structure
    
  function addPoints
    ( StudentRecord storage _studentRecord,
      uint _earnedPoints
    )
    public
    { _studentRecord.totalClassPoints += _earnedPoints;
    } // End addPoints function
} // End StudentRecord library

contract MyClass
{ // Uses the newly created StudentLibrary
  mapping ( uint => StudentLibrary.StudentRecord ) studentRoster;
  function addQuizResults() external
  { // Add points for each student from latest quiz 
    StudentLibrary.addPoints ( studentRoster[0], 10 );
    StudentLibrary.addPoints ( studentRoster[1],  5 );
    StudentLibrary.addPoints ( studentRoster[2],  8 );
  } // End addQuizResults function
} // End MyClass contract

Return to Top

In the example, the library code is saved iin the same file as contract MyClass. It could be stored in a separte file and then imported iinto the contract MyClass file. If the StudentLibrary file is kept in its own file in the same directory as the contract MyClass file StudentLibrary.sol.

In the folowing exaple, both the import and the using are used:

• The entirity of the library StudentLibrary is replaced by an import statement (Line 4)
• The Using statements extends the instances of StudentRecord with the operations iin the StudentLibrary (Line 7)
• The code is modified to use the cleaner, more easily read StudentLibrary defined function (Lines 11-13)

This form of defining and usinig a library facilitates the reuse of the library by multiple Smart Contracts, helps with the maintenance by only having the code defined once, and helps with creating Object-Oriented (OO) architectures and designs.

pragma solidity ^0.8.1;
// SPDX-License-Identifier: MIT

import StudentLibrary from "./StudentLibrary.sol";

contract MyClass
{ using StudentLibrary for StudentLibrary.StudentRecord;
  mapping ( uint => StudentLibrary.StudentRecord ) studentRoster;
  function addQuizResults() external
  { // Add points for each student from latest quiz 
    studentRoster[0].addPoints ( 10);
    studentRoster[1].addPoints (  5);
    studentRoster[2].addPoints (  8);
  } // End addQuizResults function
} // End MyClass contract