Documentation for SOOP API Library v1.0
Table of Contents

Polymorphism

Information for how SOOP handles Polymorphism


The SOOP library allows for Polymorphism to be used, as a way to allow Overloading of Members, and Methods. Overloading can be defined as in a object oriented enviroment, as defining multiple members of the like name, or multiple methods of like name, while still allowing for the original to be there. This is especially useful when you inherit other classes in the class your working with.

There's two forms of Polymorphism. The first form, involves Inheritance. This form of polymorphism uses the token identifier '::', as a way to define the structure, or if you would, path to the object your looking for.

For example, should you define a class by "MyClassA", and define a member "Apple" in it, then create a New class called "MyClassB", which Inherits from "MyClassA", when the inheritance occurs, The member "Apple" is decorated as "MyClassA::Apple". This is done, so should you decide to declare another member in MyClassB, as "Apple", you can do it, without getting Name confliction.

Should you want to refrence the Apple member in MyClassA, you would use "MyClassA::Apple". If you don't have a member named "Apple" in MyClassB, you can Refer to "Apple", and get the value of "Apple" in MyClassA's definition. However, if you have a member "Apple" declared in MyClassB, you would get MyClassB Apple's value.

This form of polymorphism also applies to methods.

The second form of Polymorphism that is used in SOOP, is the form in which member names are used, as a fast, and easier way to follow, to call methods, or get member values from classes that are defined as members of the class.

Using the Above Example, of MyClassA being defined, and the Member Apple being defined in MyClassA, but changing it, to where instead of inheriting MyClassA in MyClassB, you make it a Member called ClassB. You can retrive the value of Apple from ClassB, by using "ClassB->Apple". This makes it so that you do not have to use multiple oget()'s, or oset()'s on classes that you don't nesscarly need to.

This may not follow normal Object Oriented Polymorphism, but is viewed as the way to do it in the SOOP Library, and should be called Pathing Polymorphism.