Data

A Data library.

Architecture

DataType

Interface

The Interface declares the method signatures.

Implementation

Implements the Interface.

DataError

Interface

Declares the method signatures.

Implementation

Implements the Interface.

Library

The DataError composition. Organizes the DataError library's components.

Library

A Data composition. Organizes the Data components.

Using

Install the relevant package. The require statements change, so verify the installed version's require statement instructions. Locate them in the package's installation section's last subsection.

Data is practical in verification, classification, and exception handling.

Classification

Data is a categorization library. The Data implementation classifies Ruby types. The implementation defines five types: Numeric, TrueClass, FalseClass, Symbol, and NilClass. Numeric's children, a few being Float, Complex, Rational, Integer, are also DataTypes. The DataTypes are Ruby information types whose instances are immutable. Data becomes useful when verifying an instance is an informational type instance or an informational type identifier.

Verification

Strategically redirecting execution flow depends on conditional verification. For instance, a linked-list initialization taking either data or nodes redirects depending on a type condition.

def initialize(d_or_n = nil)
case
when DataType.instance?(d_or_n)
self.base = initialize_node(d_or_n) # Sets @base
self.size = 1 # Sets @size
when d_or_n.instance_of?(Node)
self.base = d_or_n # Sets @base
self.size = 1 # Sets @size
end
end

In the case the argument's type is a DataType, @base becomes initialize_node(d_or_n)'s return object. In the case d_or_n's type is Node, @base's setting directly becomes the argument. Verification is also involved in error detection.

Exception Handling

Error raising tunes behavior, DataError included. One particular use is constraining problematically ambiguous code. For instance, in the case an attribute was defined a DataType, and an attribute setter argument was defined ambiguously, mistakenly or accidentally argued objects become the setting, like all other arguments.

# A LinkedList class exists. The nodes store data in a data
# attribute. The data setter defines an ambiguous parameter.
# ...
# @attr data [DataType]
# Stores the Node's data.
class Node
#...
def data=(data_arg)
@data = data_arg
end
end

The @data becomes data_arg's reference. Execution continues uninterrupted regardless of the argument's type. If data_arg was a String, and @data is an operand in a later Math operation, bugs arise. Embedded bugs take time resolving, and sometimes the time is unaffordable. A solution is limiting ambiguity.

# A LinkedList class exists. The nodes store data in a data
# attribute. The data setter defines an ambiguous parameter.
# ...
# @attr data [DataType]
# Stores the Node's data.
class Node
#...
def data=(data_arg)
unless (DataType.instance?(data_arg))
raise(DataError, "#{data_arg} is not a DataType instance.")
else
@data = data_arg
end
end
end

data=(data_arg) checks the argument is a DataType instance. In the case the argument is any type other than a DataType, DataError raises. The raised DataError implies a DataType was expected somewhere. DataError's message explains the argument instance was not a DataType instance. The stack trace describes file and line locations. DataError handling communicates a DataType problem exists and the places worth inspecting. DataError shaves the debugging work.

Contributing

Open-source software has great economic and cultural utility. Organizations and individuals integrating open-source in their projects have greater resources to spend elsewhere. However, open-source solutions suffer inherent development problems affecting quality. A few of many examples are consensus requirements confounding direction, and consequently, architecture; limited resources constraining development efforts; and governance, for any number of unpredictable reasons, abandoning maintenance and development. Commercially, open-source software is untrustworthy, and for hobbyist contributors, emotionally exhausting.

The open-source problems are not insurmountable, though. Diligent Software LLC's mission is supporting externally developed public projects commercial enterprises depend on; and independently growing fundamental, reliable, and endurable open-source solutions. Hopefully, in turn, the organization's efforts effect software industrial and macroeconomic growth, and mature the open-source software community. If you are using our software, find the software useful, or in any way value Diligent Software LLC's mission, donate or participate on Github.

Data has a distinct corresponding Open Collective "Collective". The Collective coordinates communication, financial contributions, and project progression.

Development

Everyone makes mistakes. Fixing bugs one is unaware exist is impossible. Each component repository contains a 'README.md' file referring a Bug Reporting memorandum, and a Bug Fixing memorandum. In the case one discovers a bug, report the bug in the appropriate git repository. Report Data's Interface bugs in the Interface's repository. Report Implementation bugs in the Implementation repository. Report systematic bugs in the LIbrary's repository. The same applies regarding sub-projects. For instance, DataError is a sub-project. Administratively verified, follow the corresponding Bug Fixing procedure.

Additionally, every project's Library component has an additional Improvements memorandum. The memorandum describes the Improvements Procedure in the case collaborating with the organization. Independent improvements are equally welcome. The components and composition packages were released under the GNU General Public License, Version 3, so review the License's terms.

Questions

If there are commercial or private questions about Data, send contact@diligentsoftware.org an email.