At 11:20 Uhr -0600 23.09.1999, Scott Raney wrote:
>On Thu, 23 Sep 1999, Steve Long wrote:
> > 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.
We have come up with a convention: If a handler name starts with an
underscore, then it may only be called from within the same script...
it is private. We have a very large project with many people
developing, so if I change a handler, I'll have to make shure that it
is not used in a wrong way. We do have a cross reference, but it is
much easier to see right in the code "Ah! I can modify this handler
as much as I like or even delete it. It is only used here and does
not provide any general functionality."
> > 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?
The programmer has to decide if she needs a button in any script, so
she can decide if she needs a custom object... I don't think we need
any automatic persistence.
> > 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...
How about the script of a control (maybe a new control type)? The
"insert" command works like that, too! What additional properties do
we need? I can only see the class name and abbrevations. Would there
be a command that loads the class or is it loaded as soon as the
stack loads.
> > 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>,...
Now I understand what an "input" is... but I'd prefer:
create <className> [<objectName>]
set the <propertyName> of it to <propertyValue>
maybe even
create <className> [<objectName>] with <input-name> <input-value> [and ...]
e.g.
create user "Edgar" with id 41 and noseLength 425
> > 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 ;-)
Take a look at the SK8 (ex-)project at Apple (speak like "scate"). It
is a very interesting prototype of a direction that HyperCard and
AppleScript could have developed into... and it was written in Lisp!!!
>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.
I can do nothing but agree here.
Regards
R�diger
--------------------------------------------------------------------
| Ruediger zu Dohna GINIT GmbH 0721-96681-63 [EMAIL PROTECTED] |
| PGP-Fingerprint: F1 BF 9D 95 57 26 48 42 FE F8 E8 02 41 1A EE 3E |
--------------------------------------------------------------------
