OOP Principles

[JRS]

After wading through the POOP, I have made a few design decisions that I think resolve the issues, maintain the intended business logic and allow continued use a language everyone already knows.

• When SB loads it's object modules (class definition files) a default/initialized object structure is created and ready to be instantiated. Creating the new instance is really nothing more than making a copy of the base object structure and assigning it a reference ID that is uses by all other SB object external access directives.
• All object instance properties and methods may be dynamically changed at runtime under programmer control or through inheritance.
• A NEW() directive can include inherited base classes which will create the instance structures for them as well.
  
• I have elected NOT to support method overloading as defined in POOP. SB will support function overloading as it's already built into the language design. This means adding a few more methods with extended names. It consolidates existing function overloading to one definition.
  

I'm still in the proof of concept phase but things so far are looking pretty good.

[Charles Pegge]

I can see how you use arrays to hold structures, but how do you implement a method in SB?

[JRS]

I can see how you use arrays to hold structures, but how do you implement a method in SB?

Methods are stored in a mixed element/associative array structure as an ADDRESS to the function. The function (method) may be resident to the base class or the ADDRESS changed by inheritance (or programmer) to point to the inherited class base object function. All property/methods would know by their instance count what level of the object structure it's suppose to be referencing.

Here is a snippet of code from a class I'm currently working on.

Code: [Select]

_OBJ[0]{"INFO"}{"OBJ_NAME"} = "SY_Session"
_OBJ[0]{"INFO"}{"OBJ_COUNT"} = 0
_OBJ[0]{"INFO"}{"ON_CREATE"} = "REQUIRED"
_OBJ[0]{"INFO"}{"ON_DELETE"} = "REQUIRED"
_OBJ[0]{"PROPERTY"}{"Caption$"}{"VALUE"} = ""
_OBJ[0]{"PROPERTY"}{"Caption$"}{"SET"} = "ERR"
_OBJ[0]{"PROPERTY"}{"PathCompany$"}{"VALUE"} = ""
_OBJ[0]{"PROPERTY"}{"PathCompany$"}{"SET"} = "ERR"
_OBJ[0]{"PROPERTY"}{"PathUser$"}{"VALUE"} = ""
_OBJ[0]{"PROPERTY"}{"PathUser$"}{"SET"} = "ERR"
_OBJ[0]("PROPERTY"}{"PathSystem$"}{"VALUE"} = ""
_OBJ[0]("PROPERTY"}{"PathSystem$"}{"SET"} = "ERR"
_OBJ[0]("PROPERTY"}{"PathHome$"}{"VALUE"} = ""
_OBJ[0]("PROPERTY"}{"PathHome$"}{"SET"} = "ERR"
_OBJ[0]("PROPERTY"}{"PathBase$"}{"VALUE"} = ""
_OBJ[0]("PROPERTY"}{"PathBase$"}{"SET"} = "ERR"
_OBJ[0]("PROPERTY"}{"PathRoot$"}{"VALUE"} = ""
_OBJ[0]("PROPERTY"}{"PathRoot$"}{"SET"} = "ERR"
_OBJ[0]{"PROPERTY"}{"UserGroupList$"}{"VALUE"} = ""
_OBJ[0]{"PROPERTY"}{"UserGroupList$"}{"FNGET"} = ADDRESS(GET_USR_GRPS())
_OBJ[0]{"PROPERTY"}{"UserGroupList$"}{"SET"} = "ERR"

...

_OBJ[0]{"METHOD"}("Logon"} = ADDRESS(USER_LOGON())
_OBJ[0]{"METHOD"}("InitiateUI"} = ADDRESS(START_UI())
_OBJ[0]{"METHOD"}("TerminateUI"} = ADDRESS(STOP_UI())
_OBJ[0]{"METHOD"}("InitiateWinAPI"} = ADDRESS(START_WINAPI())
_OBJ[0]{"METHOD"}("LaunchProgram"} = ADDRESS(LAUNCH())
_OBJ[0]{"METHOD"}("LogonAdmin"} = ADDRESS(LOGON_ADMIN())
_OBJ[0]{"METHOD"}("LogonFromFile"} = ADDRESS(LOGON_FROM_FILE())
_OBJ[0]{"METHOD"}("OpenSessionFiles"} = ADDRESS(OPEN_SESSION_FILES())
_OBJ[0]{"METHOD"}("CloseSessionFiles"} = ADDRESS(CLOSE_SESSION_FILES())
_OBJ[0]{"METHOD"}("WriteRegistryStartupEntries"} = ADDRESS(WRITE_REGISTRY_SETUP_ENTRIES())


[Charles Pegge]

Got it! Thanks John.

One thought occured to me: associative array indexes are quite expensive. For high performance, it might be better to use numeric indices, using variable names instead of the quoted names. All you will need is an equate list for all properties and methods.

[JRS]

The expense is on creation. Once the structures are created, SB accesses them rather efficiently as they just element based arrays under the covers. The other issue with MAS is that properties and methods use the $ for string variables (remember POOP is emulated OOP) and I have to maintain the naming otherwise this would be a rewrite. (thousands of lines of code spanning over 30 years)

[Charles Pegge]

There was this note in the user manual, (following the main description of associative arrays):

The typical use of associative arrays is to get a feature like record in PASCAL or struct in language C. Note that this type of storage is less than optimal in case it is used for a huge number of keys and values.

Searching the keys in the array is linear. It means that accessing a single element needs time proportional to the size of the array.

[JRS]

The class definitions are rather small so it should work just fine. I really have no other options in this case. Speed isn't the most important factor with this project and has been traditionaally an interpreter driven product.

I created an associative based object array that had 46 element definitions. I copied that structure 1000 times. (simulating instantiating an object) This time included loading SB from the command line.

jrs@laptop:~/sb/sb22/test$ time scriba asstest.sb
Object Instance Count: 1000


real   0m0.082s
user   0m0.064s
sys   0m0.020s
jrs@laptop:~/sb/sb22/test$

Time to execute a single PRINT statement.

jrs@laptop:~/sb/sb22/test$ time scriba print.sb


real   0m0.003s
user   0m0.000s
sys   0m0.000s
jrs@laptop:~/sb/sb22/test$

[JRS]

If a programmer creates an class that is meant to be inherited, should that sub-class / child be able to be instantiated on its own?

[Charles Pegge]

I think so.

The child class will inherit all the structural definitions and method references  of its parents and add to them.


Javascript objects are quite interesting. They are a simplified form of OOP where there is no formal definition of classes.

http://www.w3schools.com/js/js_objects.asp
https://developer.mozilla.org/en/docs/JavaScript/Guide/Working_with_objects

Objects inherit directly from 'Object prototypes'

I think JavaScript OOP is  closer to what you are doing in SB than compiler-based OOPs, where types and classes are formally defined.

[JRS]

I think JavaScript OOP is  closer to what you are doing in SB than compiler-based OOPs, where types and classes are formally defined.

My goal with the SB OOP direction is to make it fully scriptable[possible new word] at runtime just as DLLC makes API access/Threading/Callbacks a dynamic scriptable interface. I view SB as the core object that everything else is a child of and using a traditional BASIC syntax for flow and structure.

The child class will inherit all the structural definitions and method references  of its parents and add to them.

That wasn't my question. I wanted to know if a object that was designed to be inherited can be instantiated as a base object. (not as inherited) From what I have been able to dig up, any object instantiated should not have to depend on external (assumed as inherited)  resources.

[Charles Pegge]

Yes, you can instantiate with base classes. Abstract classes are the ones which cannot be instantiated. (I have not tried deploying them yet)

[JRS]

Javascript objects are quite interesting. They are a simplified form of OOP where there is no formal definition of classes.

JavaScriptBasic is designed on a simple object-based paradigm. An object is a collection of properties, and a property is an association between a name and a value. A value of property can be a function, which is then known as the object's method.