On Thu, 23 Sep 1999, Steve Long wrote:
> Some good ideas. Look at C++, Java, and the Common Lisp Object System
> for implementation of the object paradigm.
>
> An object is an object is an object, and here is what (basically) should
> included to move an xTalk product away from the object-based (Hypercard,
> Metacard) design to the object-oriented design.
>
> Encapsulation - The object should be capable of containing both messages
> and methods relative to itself. Messages and methods should have free
> access to themselves within the class.
This is irrelevant: both standard and custom properties can be
accessed from anywhere, and you control access with getprop/setprop
handlers, not syntax like you would in OO languages.
> Inheritance - The object should be capable of inheriting the properties,
> child objects, and methods of at least one other object.
I don't know of any OO language allows inheritance of "child" objects,
and embedding one object in another is either not supported or is
considered poor technique (at best you'd have a pointer or reference
to the other object and do the actual creation in the constructor of
the "parent" object).
> Access - The object should be able to control access to it's own
> messages (inputs, properties, and child parts that allow chain
> referencing) and methods (functions) by declaring them as public,
> private, or protected. Properties and methods of an
> inherited class that are not of type protected can be changed by the
> inheriting class.
Again, this is supported in true from-the-ground-up OO languages, but
a hopeless incompatibility with the design and spirit of xTalk. All
properties and "methods" (actually handlers) would have to be public.
IMHO, private and protected methods and properties are more trouble
than they're worth even in C++ and Java, and are an even worse idea in
a language where freedom, productivity, and ease of learning are
valued far more than they are in these other languages.
> Persistance - The object should be capable of saving itself between
> sessions (by writing itself to a stack persistent object storage area,
> for example.)
Exactly when and how this is done is a pretty huge issue. For
example, can you only create an object in the context of some stack
that already has a filename?
> Usage - The instance of a class is what is used
>
> Obviously, backgrounds, fields, buttons, menus, etc., are examples of
> manufacturer-provided objects. I would envision defining the object with
> a
> new keyword "defineClass" like this:
And where would this "definition" be kept? There is no concept of
#include files in xTalk. If it must be attached to a stack, then
maybe it should be a property rather than written out as "code" like
it is in other languages...
> defineClass className,inheritedClass
> public:
> inputs: <input-name> .....
> properties: <property-name>: <property definition> ...
> parts: <part-name> <definition of part to be instantiated>
> ...
> methods: function <name> (<arguments>) <definition> end <name> ...
>
> private:
> properties: <property-name>: <property definition> ...
> parts: <part-name> <definition of part to be instantiated>
> ...
> methods: function <name> (<arguments>) <definition> end <name> ...
>
> protected:
> properties: <property-name>: <property definition> ...
> parts: <part-name> <definition of part to be instantiated>
> ...
> methods: function <name> (<arguments>) <definition> end <name> ...
>
> end className
Looks to me like you might as well be writing in C++ or Java ;-)
> Instantiate via function returning instance of class. If it is a menu,
> field, card,
> button, background, etc., it has the side effect of appearing on the
> screen!
>
> makeInstance (<className>,<input-name> <input-value>,...)
>
> AppleScript already does something like this.
AppleScript (like JavaScript) is another language where you can learn
a lot from the mistakes the designers made. I did quite a bit of Lisp
programming in graduate school, and the more you know Lisp, the less
AppleScript looks like xTalk and the more it looks like Lisp. This is
especially true when you get into its more advanced features (like
this OO stuff, which apparently almost nobody uses anyway, probably
because the average AS user is about as far from the average Lisp
programmer as you can get ;-) I think the design philosophy here
should be to emphasize ease of learning and ease of use rather than to
try to be true to the current OO dogma.
Regards,
Scott
> Steve Long
> -----------------------------------------------
> http://www.isomedia.com/homes/slong
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
