1. Object Oriented Programming Update
Here's an updated feature list for OOP library I'm working on. I should have an
alpha version ready for upload in the next few days.
Joe
-- Implemented features include:
-- Inheritance from multiple base classes is fully supported
-- Virtual base class inheritance ensures that each superclass is instantiated
only once
-- Virtual and non-virtual routines with name overloading are fully supported
-- Overloaded routines take precedence over inherited, although either can be
accessed
-- Constructors and destructors are fully supported
-- Default member values are supported - allows writing a Constructor to be
optional
-- Common variables for an entire class are supported
-- Common constants for an entire class are supported
-- Members can be hidden using Public, Published, Protected, and Private
access types
-- Member access can be granted to a specific non-related "friend" class
-- Type checking of member data is fully supported
-- Instantiated objects have a user-defined persistence
-- Access is by reference, so passing by reference is implied and automatic
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
2. Object Oriented Programming Update
------ =_NextPart_000_01BECC93.8DF5AF20
Well, I'm not getting much feedback from you guys any more about my OOP
project, so here's a little something to chew on:
This is the rough draft of the User's Manual for my OOP library. Please
look it over and let me know what you think. I'll try to upload the first
alpha version in a few days. Thanks...
Joe
------ =_NextPart_000_01BECC93.8DF5AF20
OOP Object Oriented Proramming Library
Version 0.8 Alpha Released 1999-07
Copyright 1999, Optimum Computing Solutions
Introduction
============
Optimum Computing Solutions is a small company that does custom
programming for small businesses and individuals. I began this
particular project (OOP) to investigate Euphoria as a language to
determine its flexibility, ease of use, performance, etc.
Please send comments, bug reports, enhancement requests, etc. to:
jotto at netzero.net
If you are a registered Euphoria user, you have the option to
contribute Euphoria dollars to help me purchase a registered copy
of Euphoria. Please exercise this option.
Overview
========
This library provides a full-featured object oriented programming
system. It should enable Euphoria programmers to exploit the
power of OOP solutions.
Implemented Features
====================
* Inheritance from multiple base classes is fully supported.
* Virtual base class inheritance is fully implemented ensuring that
each superclass is instantiated only once.
* Virtual and non-virtual methods with name overloading are fully
supported using the oopVirtual and oopNonVirtual storage types.
* Overloaded methods take precedence over inherited, although
either can be accessed using qualifies names.
* Constructors and destructors are fully supported.
* Default member values are supported. This allows the writing
of a Constructor to be optional in some cases.
* Common variables for an entire class are supported by using the
oopCommon storage type.
* Common constants for an entire class are supported by using the
oopConstant storage type.
* Members can be hidden by using oopPublic, oopPublished,
oopProtected, and oopPrivate access types.
* Member access can be granted to a specific non-related "friend"
class by using the oopFriend specifier.
* Automatic type checking of member data is fully supported.
* Instantiated objects have a user-defined persistence.
* Access to all objects is by reference, so passing by reference
is both implied and automatic.
Global Constants, Variables, Types, Functions, and Procedures
=============================================================
Information
-----------
constant oopVersion = 0.8
constant oopRelease = "1999.07"
Control
-------
boolean oopWarnings
Controls whether to display or simply ignore warning messages.
boolean oopTypeCheck
Controls whether to automatically type-check member assignments.
Basic OOP Types
---------------
type oopName (object x)
Any OOP identifier index or name
type oopMember (object x)
OOP member identifiers - identical to oopName () in this release
type oopClass (object x)
OOP class identifier
type oopInstance (object x)
OOP instance identifier
Access Types
------------
oopPublic Available externally and to any class (r/w)
oopPublished Available externally (r) and internally (r/w)
oopProtected Available only to declaring class and children
oopPrivate Available only to declaring class
Access Modes
------------
oopRead Requesting read access
oopWrite Requesting write access
Storage Type Flags
------------------
oopVirtual Nonrestrictive late binding
oopNonVirtual Simulated static binding
oopUnique Unique storage for each object instance
oopCommon Common storage for entire class
oopConstant Storage is read-only
oopDataStorage Virtual, Unique - default for data
oopRoutineStorage Virtual, Common, Constant - default for routines
Member Data Types
-----------------
oopFunction Indicates member function
oopProcedure Indicates member procedure
oopData Indicates member data
oopName Routines
----------------
function getOopName (oopName oName)
Returns the printableString used when the name was created.
oopClass Routines
-----------------
function newOopClass (printableString newClass,
sequence baseList, sequence memberList)
Creates a new oopClass with the given name, inheriting members
from all listed base classes and declaring additional members
listed.
baseList is a sequence of access types and oopClasses. The
default base class access is oopPublic.
memberList is a sequence defining new members. The pattern is
repeated for all members as follows (braces mean optional):
oopFriend, oopClass
{accessType,} oopFunction, {storageMasks,} oopName
{accessType,} oopProcedure, {storageMasks,} oopName
{accessType,} oopData, {storageMasks,} oopName, default, type_id
Example:
constant myClass = newOopClass ("myClass",
{base1, oopPrivate, base2, base3, oopProtected, base4},
{
oopPublished,
oopData, "value", 0, typeAtom,
oopData, oopCommon, "totalOps", 0, typeUnsigned,
oopFriend, myFriend,
oopPublic,
oopProcedure, "print",
oopProcedure, "=",
oopProcedure, "+"
})
procedure bindOopClass (oopClass myClass, sequence bindList)
Binds routine IDs to listed members.
bindList is a sequence of alternating oopNames and routine names.
Example:
bindOopClass (myClass,
{
"print", "realPrint",
"=", "realSetValue",
"+", "realPlus"
})
oopInstance Routines
--------------------
function oopGetClass (oopInstance instance)
Returns the oopClass to which this instance belongs.
function oopGetData (oopInstance instance, object member)
Retrieves data from the object instance.
procedure oopSetData (oopInstance instance,
object member, object theData)
Stores data in the object instance.
function oopCallFunc (oopInstance instance,
object member, sequence params)
Calls the specified member function.
procedure oopCallProc (oopInstance instance,
object member, sequence params)
Calls the specified member procedure.
function newOopInstance (object classInitList)
Instantiates a new object initialized as specified.
Global Types Provided by Types.e
================================
Routine ID Related Type
---------- ------------
typeObject *Built-in
typeSequence *Built-in
typeAtom *Built-in
typeInteger *Built-in
typeBoolean boolean (object i)
typeBit bit (object i)
typeUnsigned unsigned (object i)
typePosInt posInt (object i)
typeChar char (object ui)
typeLcChar lcChar (object c)
typeUcChar ucChar (object c)
typeControlChar controlChar (object c)
typePrintableChar printableChar (object c)
typeIntegerList integerList (object s)
typeString string (object s)
typePrintableString printableString (object s)
typeStringList stringList (object s)
typePrintableStringList printableStringList (object s)
The OOP Namespace
=================
The OOP identifier namespace consists mostly of unique printable
strings. The exceptions are anonymous OOP identifiers named "".
All OOP identifiers may be referenced by index and non-anonymous
OOP identifiers may be referenced by name.
Qualified Member Names
======================
A method that has been overloaded can still be accessed by using
the qualified name. Instead of using:
oopCallProc (myObj, oopMember, {params})
Use a qualified name indicating the hidden method's class:
oopCallProc (myObj, {oopClass, oopMember}, {params})
Explanation of Virtual / Non-virtual Methods
============================================
Scenario: Class A defines a method called myProc (). Then
class B is defined using class A as its base class, inheriting
all of class A's members. Class B then proceeds to overload
myProc () with its own method, keeping all other inherited
methods intact. An object of class B, myObj, is instantiated.
If myObj calls myProc, it will get class B's version because
of the name overloading. If myObj calls another method that
has not been overloaded, it will actually call class A's version
because it was inherited.
The difference between virtual and non-virtual methods is
outlined in this example. If myObj calls a method, prime (),
inherited from class A and *that* method calls myProc (), the
method called is resolved as follows:
If class A declared myProc () as a virtual method, prime ()
will call class B's version of myProc ().
If class A declared myProc () as a non-virtual method, prime ()
will call class A's version - even though it has been overloaded.
Declaring the method non-virtual tells the OOP system to ALWAYS
resolve unqualified references from the original class to the method
declared by that class, ignoring name overloading.
Implications of Multiple Base Inheritance
=========================================
Multiple base class inheritance allows the user to write a new
class that inherits functionality from as many base classes as
needed. Base class members may be hidden en masse using the
oopPublic, oopPublished, oopProtected, and oopPrivate access types.
Virtual base inheritance takes care of the following scenario:
Furniture
/ | \
Electronic Table Shelves
/ |
Television Stereo
A Console Television class would inherit from Television and from
Table (since it has a table top). An entertainment center would
inherit from Television, Stereo, and possibly Shelves if you were
to consider it as a whole.
In any case, the new class would inherit multiple copies of the
Furniture class and possibly the Electronic class from multiple
base classes. This causes confusion and errors due to the
inability to resolve the needed copy of the base class. Virtual
base class inheritance solves the problem by automatically
combining the multiple copies of the base class into a single
copy for use.
End User License Agreement (EULA)
=================================
This software library may be utilized for personal use free of
charge.
The compressed archive containing the files that comprise this
software library may be freely distributed for development or
educational purposes as long as it made is made available free of
charge. A new archive may be freely distributed for development
or educational purposes as long as 1) It is made available free
of charge; 2) All the files in the original archive are included
and are not altered in any way.
This software library may be used and distributed without royalties
in the context of a released software package only if ALL of the
following conditions are true:
1) The resulting software package must be distributed as freeware.
If you charge money or otherwise receive money for the software
package, you MUST FIRST work out a royalty agreement or a new
licensing arrangement with Optimum Computing Solutions.
2) All files that were provided with this library are included
in the distribution of the resulting software package.
3) If technically possible, the source code for this library
shall be shrouded.
This software product is provided "as is" without warranty of any kind.
In no event shall Optimum Computing Solutions be held liable for any
damages arising from the use, misuse, or inability to use this product.
Copyright 1999, Optimum Computing Solutions
All rights reserved
------ =_NextPart_000_01BECC93.8DF5AF20--
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
3. Re: Object Oriented Programming Update
Can data be oopPublic, oopPublished, oopProtected, oopPrivate
for OOP data hiding ??
Bernie
4. Re: Object Oriented Programming Update
Joe Otto wrote:
> Well, I'm not getting much feedback from you
> guys any more about my OOP project, so here's
> a little something to chew on ...
The EULA is a bit odd. You require that (1) all files included in the
resulting software package be included, and (2) the source code to the
library be shrouded. These seem to be mutually exclusive goals. You also use
the words "personal use" and "development" as if they were equivalent, but
it's clear that this isn't your intent.
The documentation says "I'm poor - give me money!" all over the place, from
your e-mail address (netzero), requesting Euphoria dollars, requirement of
payment if used in a real application, and so on. This is a bit distracting.
More problematic, the documentation fails to give a feel for what the
library is like. No complete examples are given, nor is any explanation of
what "exploit the power of OOP solutions" might mean. After reading through
the documentation, I'm still left wondering why I'd want to add all this
complexity on top of Euphoria. What problem will using this library solve?
Including a cool demo application that demonstrates features difficult to
accomplish without your library would be a good thing.
-- David Cuny
5. Re: Object Oriented Programming Update
- Posted by Joe Otto <jotto at NETZERO.NET>
Jul 12, 1999
-
Last edited Jul 13, 1999
Bernie,
I'm not sure I understand your question... If you're asking whether data
as well as methods can be "hidden" then the answer is yes.
If you're asking for more background, they are given to object members to
specify how access is to be granted and to what sections of code.
For example (albeit a poor one), if you're writing a program that uses
objects to implement complex numbers, the underlying implementation should
be unimportant and thus hidden from the programmer. Whoever is using the
objects doesn't need to know whether you're actually storing a real and a
complex part or an angle and magnitude.
The complex number example is pretty lame... If you wrote a large library
and you didn't want the end user to have to worry about your implementation
details, you could flag them as oopPrivate to keep any user-written child
objects from reading or overwriting your object's members. All you would
need to expose via oopPublic is whatever members implement the application
interface. That's a more appropriate example - but a little harder to
imagine.
Hope I answered your question...
Joe
-----Original Message-----
From: Bernie Ryan [SMTP:bwryan at PCOM.NET]
Sent: Monday, July 12, 1999 6:48 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Object Oriented Programming Update
Can data be oopPublic, oopPublished, oopProtected, oopPrivate
for OOP data hiding ??
Bernie
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
6. Re: Object Oriented Programming Update
- Posted by Joe Otto <jotto at NETZERO.NET>
Jul 12, 1999
-
Last edited Jul 13, 1999
David,
Thank you for taking the time to read the file, and thanks for your
comments. I'm sorry all the verbiage was distracting. I put most of it at
the bottom of the file in the hopes that it wouldn't be too much of a
bother. I'll look at it again. But for now, please allow me to clarify my
position...
My company, Optimum Computing Solutions, was in the business of selling
PCs and servers until the Compaq/Dell/Gateway squeeze made it too hard
(virtually impossible) to actually make a profit on a sale. I've been
programming on and off for about 21 years and still enjoy doing it, so I've
decided to redirect my efforts into the software arena. What you read in
"oop.txt" was actually my very first attempt at writing a EULA. All I
really mean for it to say is take the code, play with it, work with it,
have fun with it, learn with it, teach with it, and freely give it to
anybody else that wants to do the same. If you want to make money with it,
then go ahead and do so, but please share some of the income with me (my
company). I'm sorry for the confusion.
It seems like most of the people on this mailing list treat coding as a
hobby. If that's the case, feel free to take my OOP library and have a
great time with it. I'm sure that when I release the code, you'll find
plenty of things in it interesting and probably more than a few shining
examples of what not to do. At the very least it has been and will
continue to be a learning experience for me.
As far as your other comments go, I'm not very good at documentation (as
you can tell). What would you suggest I do to help others get a feel for
what the library is like? I know a complete example would help, but I
haven't had a chance to write a decent one yet. I'm also having trouble
thinking of a good app to write to showcase the library. I would
appreciate any suggestions any of you may have. Thanks again...
Joe
-----Original Message-----
From: Cuny, David [SMTP:David.Cuny at DSS.CA.GOV]
Sent: Monday, July 12, 1999 6:58 PM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: Object Oriented Programming Update
Joe Otto wrote:
> Well, I'm not getting much feedback from you
> guys any more about my OOP project, so here's
> a little something to chew on ...
The EULA is a bit odd. You require that (1) all files included in the
resulting software package be included, and (2) the source code to the
library be shrouded. These seem to be mutually exclusive goals. You also
use
the words "personal use" and "development" as if they were equivalent, but
it's clear that this isn't your intent.
The documentation says "I'm poor - give me money!" all over the place, from
your e-mail address (netzero), requesting Euphoria dollars, requirement of
payment if used in a real application, and so on. This is a bit
distracting.
More problematic, the documentation fails to give a feel for what the
library is like. No complete examples are given, nor is any explanation of
what "exploit the power of OOP solutions" might mean. After reading through
the documentation, I'm still left wondering why I'd want to add all this
complexity on top of Euphoria. What problem will using this library solve?
Including a cool demo application that demonstrates features difficult to
accomplish without your library would be a good thing.
-- David Cuny
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
7. Re: Object Oriented Programming Update
- Posted by David Cuny <dcuny at LANSET.COM>
Jul 12, 1999
-
Last edited Jul 13, 1999
Joe Otto wrote:
> What you read in "oop.txt" was actually my very first
> attempt at writing a EULA. All I really mean for it to say
> is take the code, play with it, work with it, have fun with it,
> learn with it, teach with it, and freely give it to anybody else
> that wants to do the same. If you want to make money with it,
>then go ahead and do so, but please share some of the income
> with me (my company). I'm sorry for the confusion.
That's an *excellent* EULA, right there. 
> It seems like most of the people on this mailing
> list treat coding as a hobby.
I think that's accurate. I also get the impression that most people on this
list are equally strapped for cash. And the registered ones forget to
vote...
> I'm also having trouble thinking of a good app
> to write to showcase the library.
I really think that a strong demo is the key to selling the library.Colin
Taylor's Vega library is an excellent example, as well as some of Jiri's
stuff. If you can't think of a great use for your library, I'm not sure
others will, either.
I also suspect that a library built with your OOP library is probably much
more valuable than the library itself. So if you come up with a "killer app"
demo, you might consider that as your product instead of the OOP library.
A game application framework seems like a good idea. Michael Packard did
something similar a while back (and got far too much harassment from me
about being "too commerical" for this list). Pick a good video and sound
library (they've already been written), and build a game application
framework.
By "game application framework", I'm not thinking of just providing the bits
and pieces that the libraries already supply. The application framework
would provide a *complete* framework for game creation. For example, all the
player would have to do is write something like this:
myGame = new( GenericVideoGame )
sendMessage( myGame, play )
and a complete generic game (along with sound effects, scoring, title
graphics, logic, enemies and so on) would be created. Mind you, it wouldn't
necessarily be an *interesting* game, but it would be complete.
You could then override the base classes to create a new game. For example,
change the sprites, backgrounds and some text, and you have a customized
game.
As I've noted, all the bits and pieces are already out there - sprite
management, collision detection, sound effects, fonts. All you would need to
do is write a basic game that glues all these bits and pieces together. That
game would serve as your game library, from which you could derive other
games.
Just a thought.
Good luck!
-- David Cuny
