Differences

This shows you the differences between two versions of the page.

--- dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:start [2021/11/03 21:07]
nick [Abstract/Virtual Methods]
+++ dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:start [2022/03/22 13:32] (current)
char [Overview]
@@ Line 2: / Line 2: @@
 [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:start| Return to Data Taxonomy]]
-In programming, an [[dido:public:ra:xapend:xapend.a_glossary:o:object]] represents a real-world object such as a car, an employee or a task. Ultimately, as the real-world Object is defined in terms of software, it is translated to a [[dido:public:ra:xapend:xapend.a_glossary:d:datastructure]]. The Object Data (see Figure {{ref>ObjctDataTax}} is categorized into Characteristic Data, Definition Data, Field Data and Operation Data.
+===== Overview =====
+[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:start | Return to Top]]
+In programming, an [[dido:public:ra:xapend:xapend.a_glossary:o:object]] represents a real-world object such as a car, an employee or a task. Ultimately, as the real-world Object is defined in terms of software, it is translated to a [[dido:public:ra:xapend:xapend.a_glossary:d:datastructure]]. The Object Data (see Figure {{ref>ObjctDataTax}}) is categorized into Characteristic Data, Definition Data, Field Data and Operation Data.
 <figure ObjctDataTax>
@@ Line 10: / Line 13: @@
 ===== DIDO Specifics =====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
+[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects:start | Return to Top]]
-Many DIDO Platofrms refer to Object Data as **Smart Contracts**.
+Many [[dido:public:ra:1.2_views:1_stakeholder:1_platform | DIDO Platforms]] refer to Object Data as **[[dido:public:ra:xapend:xapend.a_glossary:s:smart_contract| Smart Contracts]]**. These are similar too, but not the same as classes in [[dido:public:ra:xapend:xapend.a_glossary:o:oop]] languages such as C++, Java, C#, Python, etc. In many ways, the differences are lexical in nature (i.e., **''Smart Contract''** versus **''Contract''**, **''method''** versus **''function''**, etc. However, there are some important differences which have to do with the distributed nature of DIDOs and the immutability of the field data (i.e., **view** and **pure** designators on **methods**.
-===== Characteristic Data =====
+The following discussion has to do with the more generic concept of **Object Data** but does include discussions of how it relates to DIDO Platforms in general and [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:ethereum_solidity:start| Ethereum's Solidity]] more specifically.
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-Every Object has characteristics that contextually describe the object. For example, the Object's name, if it implements and interfaces or if it is an extension of another object.
-  * **Name** is a textual name that uniquely identifies the object with the context of the [[dido:public:ra:xapend:xapend.a_glossary:n:namespace]]. For example, there are multiple objects with the name of **Tank**. The first is in the namespace (i.e., context) of the oil and gas industry and refers to a fuel tank. Another **Tank** object has a military namespace and refers to a military vehicle, and another **Tank** object has a clothing namespace and refers to a "tank top" tee-shirt. All the rest of the data for the object is dependent on context (i.e., namespace).
-  * **Implements** is a way to describe which [[dido:public:ra:xapend:xapend.a_glossary:i:interface | Interfaces]] this object provides an implementation for. For example, the [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0020 | ERC-20]] interface used for many [[dido:public:ra:xapend:xapend.a_glossary:c:cryptocurrency | Cryptocurrencies]]. [[dido:public:ra:xapend:xapend.b_stds:defact:orcle:java | Java]] defines standardized collection interfaces for things like Lists, Set, Queue, Maps and Iterators((
-Programiz.com
-__Java Collection Frameworks__,
-Accessed: 27 October 2021,
-[[https://www.programiz.com/java-programming/collections]]
-)). C++ has similar interfaces to those describe for Java ((
-Geeksforgeeks.com,
-__The C++ Standard Template Library (STL)__,
-Accessed: Accessed: 27 October 2021,
-[[https://www.geeksforgeeks.org/the-c-standard-template-library-stl/]]
-)). The exact way that interfaces are implemented differs from language to language, and can even differ from versions of the same language.
-  * **Extends** is a way to describe a hierarchical tree for an object (i.e., its [[dido:public:ra:xapend:xapend.a_glossary:i:inheritance]]). For example, a graphics program ma have a base object called a **''GeographicShape'''**. Other objects within the graphics program such as **''Square''**, **''Circle''** and **''Triangle''** are said to **extend** the original definition of **''GeographicShape''**.
-==== DIDO Specifics ====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-Smart Contracts are akin to classes in [[dido:public:ra:xapend:xapend.a_glossary:o:oop]] languages, and they can have [[dido:public:ra:xapend:xapend.a_glossary:i:inheritance]] and [[dido:public:ra:xapend:xapend.a_glossary:i:interface | Interfaces]]. There are two very well-known examples of **interfaces** in use within [[dido:public:ra:xapend:xapend.a_glossary:e:ethereum]]:
-  * [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0020]]
-  * [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0721]]
-However, all many of the [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip]] define interfaces.
-===== Definition Data =====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-An Object has the ability to **Define Data** that can be accessed throughout the rest of the Object and depending on the public/private attribution of the definitions outside the Object Definition. The kinds of components that can be defined are:
-  * **[[dido:public:ra:xapend:xapend.a_glossary:e:exception | Exceptions]]**, or faults, are abnormal or unprecedented events occurring during or after the execution of an operation which adversely affects the flow of the operation or the flow of the operations that use the object. Although must runtime systems define some standard exceptions such as Array-out-of-bounds, divide-by-zero, or Runtime, each Data object may define its own exceptions based upon the unique characteristics of the operations. For example, a Thermostat object might have a Too-Cold or Too-Hot exception. It is a runtime error of an undesired result or event affecting normal program flow.
-  * **Structures** or **Objects** are closely related. The easiest way to think of the difference between **Structures** and **Objects** is that structures usually only define the actual data, and object (i.e., [[dido:public:ra:xapend:xapend.a_glossary:c:class]]) defines the data structures as well as operations that can be performed on that data. Object Data is a recursive definition. However in C++, the main difference between a structure and a class (i.e., object) is the assumption of public/private attribution. Structures assume that all components are by default **''public''** while classes (i.e., objects) assume that all components are **''private''**. For example, a Thermostat object might define a TemperatureReading structure that is uses to report results.
-  * **[[dido:public:ra:xapend:xapend.a_glossary:d:data_type]]** are definitions of type information associated with the object. [[dido:public:ra:xapend:xapend.a_glossary:d:data_type]] information and be numeric that include ranges, enumerations, scalars or collections. For example, the Thermostat might include a type describing the legal range of numeric values, it might define an enumeration type for Fahrenheit, Celsius or Calvin. It might also define a type for array of temperature readings.
-  : **Note:** These components are not required by any Object and the names used to describe these components can be different depending on the programming language.
-===== Field Data =====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-**Field Data**, or **Element Data**,  are the values stored within the Object and in many ways represent the reason for the Object (i.e., [[dido:public:ra:xapend:xapend.a_glossary:c:class]] in C++ or Java) to exist. In [[dido:public:ra:xapend:xapend.a_glossary:p:procedurallanguage]]) **Field Data** can be thought of as a [[dido:public:ra:xapend:xapend.a_glossary:v:variable]] with some variables having their values set at compile time (i.e., constants) and those during the execution of the procedure. **Note:** [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects#operation_data | Methods or Operations]] in Objects are procedural in nature, generally represented by a block of code that executes from the top to the bottom, but can be circuitous within the block of code having logical expressions, looping and exceptions to control the flow within the block.
-**Constant Data** is a quality of the data to not be modifiable during the execution of the procedure. There are two broad categories of constants: **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility#named_constants | Named Constants]]** and **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility#literal_constants | Literal COnstants]]**. **Note:** **Constants** can be scoped to the particular procedure, the package of procedures or during the execution of the program.
-Often the two terms: **Attribute** and **Property** are used interchangeable in Computer Science because we often use them to describe the fields (i.e., elements) of an [[dido:public:ra:xapend:xapend.a_glossary:o:object]] in an [[dido:public:ra:xapend:xapend.a_glossary:o:oop]]. However, it is useful to understand the difference between the two grammatically:
-**Attribute Data** is a quality or object that we attribute to someone or something. For example, intelligence is an attribute of a person. You can not go to the store and buy intelligence, it is an attribute of the individual. Another example would be a planet belonging to a solar system. Planets do not usually exist outside a solar system.
-**Property Data** is a quality that exists without any attribution. Geometric shapes are properties in their own right. They can be used to independently describe many things. For example, a planet or a ball can be described as a sphere((
-Sphere, In geometry, the set of all points in three-dimensional space lying the same distance (the radius) from a given point (the center), or the result of rotating a circle about one of its diameters. The components and properties of a sphere are analogous to those of a circle.[[https://www.britannica.com/science/sphere]]
-)). A definition of the sphere exists without the attribution to a planet or a ball. Therefore, we say that a planet or a ball have spherical properties.
-In [[dido:public:ra:xapend:xapend.a_glossary:u:uml]], an **Attribute** and a **Property** both represent an structural association between two entities. **Attributes** are most often represented as **Composition**((
-The **Composition** is a part of aggregation, and it portrays the whole-part relationship. It depicts dependency between a composite (parent) and its parts (children), which means that if the composite is discarded, so will its parts get deleted. It exists between similar objects.
-[[https://www.javatpoint.com/uml-association-vs-aggregation-vs-composition]]
-)), while **Property** is best represented by **Aggregation** ((
-Aggregation is a subset of association, is a collection of different things. It represents has a relationship.
-  * It is more specific than an association
-  * It describes a part-whole or part-of relationship
-  * It is a binary association, i.e., it only involves two classes
-  * It is a kind of relationship in which the child is independent of its parent.
-[[https://www.javatpoint.com/uml-association-vs-aggregation-vs-composition]]
-)).
-According to Lenny Delligatti((
-Lenny Delligatti,
-__SysML Distilled: A Brief Guide to the Systems Modeling Language__,
-FIrst Edition,
-Addison-Wesley Professional ,
-November 2013,
-ISBN-13: 978-0321927866
-)), "UML Attributes are [[dido:public:ra:xapend:xapend.a_glossary:d:data_type | Data Types]] (e.g., Strings, Integers, etc.) whereas [[dido:public:ra:xapend:xapend.a_glossary:s:sysml]] properties are ValueTypes (e.g., can be assigned computed values)."
-There are different ways that **Field Data** can be stored. In most programming paradigms, the **Field Data** is **Mutable**, meaning the values simply replaced or overwritten with new values. The Object Accessor Methods and responsible for making sure the new values are syntactically and semantically correct. Figure {{ref>mutableData}} graphically illustrates the concept of **''mutable''**. Each time the **''setter''** is called, the contents of the **Field Data** within the **Data Object** is changed. **Note:** There can be **''setters''** for **Attribute** and **Property** data. In the example, the first time the **''setter''** is called, the value of the **attribute** is set to **''2''**, the next time it is **''4''**.
-<figure mutableData>
-{{  :dido:public:ra:1.2_views:3_taxonomic:4_data_tax:screen_shot_2021-10-31_at_6.18.15_pm.png?700  |}}
-<caption>Each time the **''setter''** is called, the value of the **''Filed Data''** is changed.</caption>
-</figure>
-However, in DIDOs, most of the **Field Data** is considered **immutable**, meaning that updates and modifications to the **Field Data** are made while not destroying the previous data, but a new entry is made for the Field Data that points back to the original value. See Section [[dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:mmutable]] and Figure See Figure {{ref>ImmutableDO}}. **Note:** The concepts of **mutable** and **immutable** are different from those built into C/C++, which describes **immutable** more like constants.
-<figure ImmutableDO>
-{{   :dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:screen_shot_2021-05-22_at_11.01.39_am.png?600  |}}
-<caption>The Immutable Data Chain where the current value of a **Field Data** points to the previous value.</caption>
-</figure>
-===== Operation Data =====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-Any particular operation within an Object is generally [[dido:public:ra:xapend:xapend.a_glossary:i:imperative | Imperative]] in nature. This means that the Operations are composed of a set of statements. As the program steps through the Operation and executes each statement (i.e., instruction) the state of the Object is changed. Some statements change the values of the **Field Data** while others change the flow of execution through [[dido:public:ra:xapend:xapend.a_glossary:c:control_flow]] operations (i.e., **''IF / ELSE IF / ELSE / ENDIF''**, or **''FOR LOOPS  | WHILE LOOPS /''**, etc.).
-As the statements are executed, the **''Program Counter''** for the Operation is also modified. **Note:** Rarely all the statements contained within a single operation, but relies on calling and executing other Operations. Therefore, most Operations are also considered a [[dido:public:ra:xapend:xapend.a_glossary:p:procedurallanguage]]. Figure {{ref>ImperativeProcedural}} provides a graphic of the difference between **Imperative** and **Procedural** Programs.
-<figure ImperativeProcedural>
-{{  :dido:public:ra:1.2_views:3_taxonomic:4_data_tax:screen_shot_2021-10-31_at_4.12.07_pm.png?800  |}}
-<caption>The difference between **Imperative** and **Procedural** Programming.</caption>
-</figure>
-=== DIDO Specifics ===
-One of the interesting phenomenons about many of the [[dido:public:ra:1.2_views:1_stakeholder:1_platform | DIDO Platforms]], is the way they treat **Operation Data**. Many of the [[dido:public:ra:xapend:xapend.a_glossary:p:platform | Platforms]] not only distribute the **Field Data** using **[[dido:public:ra:xapend:xapend.a_glossary:d:distributed_ledgers]]** or **[[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:3_xdata:1_jrnl | Journal]]**, they also distribute the  **Operation Data** in the same way (in essence, treating the software just as any other data). When changes are made to the **Operation Data**, a **[[dido:public:ra:1.2_views:2_tech_views:2-nodenet:3_nodearch:2_ido:2_trans | Transaction]]** is created to be pushed to the **[[dido:public:ra:xapend:xapend.a_glossary:n:node_network]]**.
-==== Constructor / Destructor Methods ====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-=== Constructor ===
-A **Constructor** is a special group of Operators that are called when an **Object** is first created. In most [[dido:public:ra:xapend:xapend.a_glossary:o:oop]] languages (i.e., C++, Java and C#, e.g.), the **Constructor** has the same name as the **Object**. It is the initial stage in the Lifecycle of Object Data (see [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:05_lifecycle]]). For example, for an **Object** called **''Vehicle''**, the **Constructor** would also be called **''Vehicle''**. The constructor is responsible for the setup of the **Object**: the initialization of **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:08_objects#field_data | Field Data]]**, the allocation of memory from the **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility#heap_data | Heap]]**. For example, if there are dynamic Field Data, then the memory needed for those Fields is usually allocated from the **Heap**. Although **Constants** are generally managed and allocated by the compiler and are from the **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility#stack_data | Stack]]**, **[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility#static_data | Static Field Data]]** can be allocated from the **Heap** and can be set during construction. For example, the values of **Field Data** initialized by using initialization parameters on the **Constructor** or read from initialization or setup files.
-There is always a default **Constructor** that required no parameters, however, there can be other **Constructors** allowing for the passing of values to be used during initialization. For example, the minimum or maximum values used for the Field Data.
-Regardless of the number of **Constructors**, there is always a **Constructor** that is called when an object is created. Often the calling of a **Constructor** is automatic and used the default **Constructor**, but the programmer can use any of the **Constructors** defined for the **Object**. See: [[https://www.tutorialspoint.com/solidity/solidity_constructors.htm]]
-=== DIDO Specifics ===
-When Data Object is deployed in Ethereum, the following occurs:
-The contract is initialized using the **Constructor** method named: **''constructor()''**
-  : //**Constructor** is a special function declared using constructor keyword. It is an optional function and is used to initialize state variables of a contract. Following are the key characteristics of a constructor.//
-    * //A contract can have only one constructor.//
-    * //A constructor code is executed once when a contract is created, and it is used to initialize contract state.//
-    * //After a constructor code executed, the final code is deployed to blockchain. This code include public functions and code reachable through public functions. Constructor code or any internal method used only by constructor are not included in final code//
-    * //A constructor can be either public or internal.//
-    * //A internal constructor marks the contract as abstract//
-    * //In case, no constructor is defined, a default constructor is present in the contract//
-  * **Note:** See [[https://www.tutorialspoint.com/solidity/solidity_constructors.htm]]
-=== Destructor ===
-**Destructor** is a special method called automatically during the destruction of an object. Actions executed in the destructor include the following:
-  * Recovering [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility#heap_data | Heap]] space allocated during the lifetime of an object (see [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:05_lifecycle]])
-  * Releasing [[dido:public:ra:xapend:xapend.a_glossary:s:shared_resources | Shared or Network Resources]] such as printers, faxes, scanners or outside Voice over Internet Protocol (VOIP) resources
-  * Releasing [[dido:public:ra:xapend:xapend.a_glossary:r:resource_lock]], for example, Web Servers, banking systems read versus update, travel reservations, etc
-  * Closing connections such as database, file or service
-  * Other housekeeping tasks
-  * **Note:** Often the first use of the **Destructor**, Recovering **Heap** memory, is automated in many modern systems (i.e., Java, .NET, Python, JavaScript, etc.) but the remaining reasons for a destructor remain in place, and it is up to the architect to determine what resources need to be freed upon the end of a Data Object (see [[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:05_lifecycle]]).
-=== DIDO Specifics ===
-When Data Object is destoryed in Ethereum, the following occurs:
-  * A contract can be destructed via the **''selfdestruct()''** method or the deprecated **''suicide()''** method
-  * **Note:** See [[https://www.tutorialspoint.com/solidity/solidity_constructors.htm]]
-==== Accessor / Mutator Methods ====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-An **Accessor Method** is an Operation defined by [[dido:public:ra:xapend:xapend.a_glossary:o:oop]] providing access to **Field Data**. There are generally two **Accessor Methods** defined: **''get''** and **''set''**. In some  [[dido:public:ra:xapend:xapend.a_glossary:o:oo]] paradigms, the **Accessor** methods are further defined as:
-  * **Accessor Methods** provide Read-Only access to the **Field Data**. **Accessor Methods** provide a way to obtain the state of an object's **Field Data** from outside the **[[dido:public:ra:xapend:xapend.a_glossary:o:object]]**.
-  * **Mutator Methods** provide a Write-Only access to the **Field Data**. A Mutator not only does simple checking of the data being set such as type and bound checking; it can also check the semantics of the **Field Data** to ensure they are valid and consistent. For example, using a **Mutex Method** to deduct a payment, might also set the date of the payment at the same time even though they are separate **Fields** within the **Object**.
-  : **Note:** There may or may not be any [[dido:public:ra:xapend:xapend.a_glossary:m:mutex]] or [[dido:public:ra:xapend:xapend.a_glossary:r:resource_lock]] associated with the **Field Data**.
-  : **Note:** Often both the **Accessor** and the **Mutator** are simply referred to as the **Accessors**.
-  " **Note:** Both the **Accessor** and the **Mutator** are designated as **public**, but they can also be declares as **private** or **protected**. Those that are designated **Private** can only be used from within the **Object**. **Public** designations allow for the methods to be used from inside and outside the **Object**. **Protected** allows the internal **Object Methods** to access the methods, but also allows any **Objects** derived from the **Object** to access the methods.
-Some benefits of using a **Mutator Methods** include:
-  * The prevention of data corruption by directly accessing the private **Field Data** of an **Object**
-  * The flexibility in modifying the internal representation of the **Data Fields** of an **Object** without breaking the [[dido:public:ra:xapend:xapend.a_glossary:i:interface]] and consequently code that depends on the **Interface**.
-  * The ability to include additional processing logic such as validation of a value set, triggering of events, etc. during mutation of the **Field Data** or adding [[dido:public:ra:xapend:xapend.a_glossary:d:datalog]] of acccesses.
-  * The ability to add [[dido:public:ra:xapend:xapend.a_glossary:m:mutex]] or [[dido:public:ra:xapend:xapend.a_glossary:r:resource_lock]] for synchronizing multithreading or multiprocessor scenarios.
-  * The ability to define **Accessor** and  **Mutator** methods in derived **Data Objects** from the base **Data Object**.
-=== DIDO Secifics ====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-Ethereum's Solidity **View** can attribute Methods as **View**. methods ensure they do not modify the Data Object state.
-  : //A method can be declared as view. The following statements if present in the method are considered modifying the state and the compiler throws warning in such cases.//
-  * //Modifying state variables//
-  * //Emitting events//
-  * //Creating other contracts//
-  * //Using **''selfdestruct''**//
-  * //Sending **'' via calls''**//
-  * //Calling any method which is not marked **view** or **pure**//
-  * //Using low-level calls//
-  * //Using inline assembly containing certain opcodes//
-Getter Method (i.e., **Accessor Methods** are by default **view** methods.
-  * **Note:** See: [[https://www.tutorialspoint.com/solidity/solidity_view_functions.htm]]
-Ethereum's Solidity can attribute Methods as **Pure**.
-  : //Pure methods ensure that they not read or modify the state. A method can be declared as pure. The following statements if present in the method are considered reading the state and compiler will throw warning in such cases.//
-    * //Reading state variables.//
-    * //Accessing address(this).balance or <address>.balance.//
-    * //Accessing any of the special variable of **''block''**, **''tx''**, **''msg''** (**''msg.sig''** and **''msg.data''** can be read).//
-    * //Calling any method not marked pure.//
-    * //Using inline assembly that contains certain opcodes.//
-  : //**Pure** methods can use the **''revert()''** and **''require()''** functions to revert potential state changes if an error occurs.//
-  * **Note:** See: [[https://www.tutorialspoint.com/solidity/solidity_pure_functions.htm]]
-==== Abstract/Virtual Methods ====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-An **Abstract Method**, or **Virtual Method**, are methods that are declared but have no underlying implementation (i.e., no body). The primary purpose of these methods is to form a base, template or guide for subsequent Data Objects derived from this **Data Object**. The derived Data Objects all have the same behavior defined by Abstract Methods of the base object. The original base **Data Object** is considered as Abstract or Virtual since without an implementation for these methods, the **Data Object** remains a "concept".
-Almost all [[dido:public:ra:xapend:xapend.a_glossary:o:oop]] languages provide for the concept of **Abstract** or **Virtual** methods. In recent years, the concept of **Virtual** or **Abstract** **Data Objects** have lost favor to the use of **Generics** or **Templates** which can be instantiated for a particular type. For example, a double-linked-lst template, or a name-value pair template.
-<figure>
-{{  :dido:public:ra:1.2_views:3_taxonomic:4_data_tax:screen_shot_2021-11-03_at_6.05.06_pm.png?600  |}}
-<caption>Relationship of Abstract Interfaces with realized Data Objects</caption>
-</figure>
-==== General Methods ====
-[[dido:public:ra:1.2_views:3_taxonomic:4_data_tax:07_volitility | Return to Top]]
-<color blue><todo @char>New Section -- review </todo></color>
+<nspages -tree -exclude -subns -pagesInNs -h1 -textNs="">
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

DIDO Wiki

User Tools

Site Tools

Differences

Page Tools