At 12:56 Uhr -0600 24.09.1999, Scott Raney wrote:
> > >But what happens when you change the parent/class/template object?
> > Hmmmm... how about a "resizeObject" message?
>
>It would have to be more general than that. For example, if you
>change the "parent's" font, objects "derived" from it would have to be
>notified so that they could resize controls.
I think we could live without this message, but if you dont like a
"fontChanged" message, how about a generic "resize" message?
>(We also need to work on terminology some here: I think what we're
>talking about here is not really parent and child objects, nor is it
>class and instance, nor is it really "inheritance").
It is a question of what metaphor to use, a biological, a linguistic,
or something else. What is the easiest for a novice to learn, I don't
know.
> > >a "sharedScript" property
> > And "sharedToolTip", and, and, and
> > ... I think the idea of a "living template" is easier to grasp.
>
>Probably, but I can still forsee a lot of confusion about what exactly
>the result will be when the "template" is changed...
That is why it must not be named a "template". I like "class".
> > Better take a look at Serf, where you can
> > simply place a stack on a card like any other object. It is an easy
>> concept that makes tabbed views much easier to handle than in
> > MetaCard (they are actually cards on the substack).
>
>I don't see what's so hard about that.
It is not hard, but Serf is more elegant at this point.
>Can you edit the controls in place in Serf?
Yes. You can even drag and drop an object into and out of the
substack with the border hilite showing you what you are doing. The
card names are the tab labels, so you can rename, add, remove, or
reorder tabs without changing any scripts.
>This whole issue of what the "class" looks like and where it is
>stored is the major hurdle we face because there is currently no
>concept like this in any xTalk-based tool.
But I am very confident, we can create one.
> > > > >> non-control objects and classes
>> >
>> >Where would a non-physical object be placed in the inheritance structure?
>>
>> As it is not on a card, background, or stack, it should be placed
>> outside... but before the stacksInUse.
>
>I think this confuses the message heirarchy, which is constrained by
>structure, from a class hierarchy, which wouldn't be (and which in
>fact couldn't have any structure because it has no instances).
>This "class" based inheritance (and message path) would be independent
>of the current "structure" based architecture. Attributes (and
>messages) would just come from the "class" before the "structure".
True.
> > Even a garbage collection has to find out if there are still
> > references to an object.
>The need to figure stuff like this out on the fly is why garbage
>collection is slow, and why we want to avoid designs that rely on it.
Even if we wanted, we could not!
>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 ;-)
The average AppleScript is propably less than 20K and OO features are
needed in large projects only, that's why.
> > > As long as you're sticking with the there's-always-a-physical-instance
> > > architecture, it's not really a class, which is good because it's
> > > probably much simpler for people to learn how to use.
> > If we add non-physical objects to the mix, it would be easy to mess
> > things up.
>I think I agree. But this does limit our options because it
>eliminates user-defined classes from the discussion. Perhaps we ought
>to concentrate on expanding the custom property system instead...
Wait!!! Ok, if I am the only one who needs custom classes as well as
custom properties, I'll stop asking, but we are working with a lot of
complex objects that are stored in a database. The only way to
manipulate them now is to load them in a textual representation into
a global variable and call handlers to do the stuff. It does work,
but the code is not very readable and maitainability could be better,
if only custom classes where available.
xTalk can be used by a beginner, but also advanced programmers can
benefit from its ease of use. Custom classes would be a feature for
large projects, making MetaCard more mature. Not all MetaCard
concepts are easily understood by newbies anyway, like backgrounds
being a synonym to groups. I am committed to ease of use, and
sometimes adding functionality can make things easier, because you
need fewer workarounds.
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 |
--------------------------------------------------------------------
