At 19:31 Uhr -0600 23.09.1999, Scott Raney wrote:
>On Thu, 23 Sep 1999, Ruediger zu Dohna wrote:
>
>> At 11:05 Uhr -0600 22.09.1999, Scott Raney wrote:
>> >On Wed, 22 Sep 1999, Ruediger zu Dohna wrote:
>> > > A group class (aka background class) would even have several objects
> > > > tied together to act as one custom control type.
> > >inheriting composite objects would be quite a different thing.
> > set the titlePosition of dbFld 1 to left
>> Relocates the title field, but leaves the main field where it is,
>> resizing the group accordingly.
>
>But what happens when you change the parent/class/template object? I
>don't see how you can have the derived objects show the new control in
>any sensible way if they've been altered in any way...
Hmmmm... how about a "resizeObject" message?
> > >It sounds to me more like what you want is a way to place a group in
>> >stacks other than the stack's it's in.
>>
>> Closely ralated to that, but you can place a group only once on a
>> card and you can not overload any scripts. Groups have some behaviour
>> of a class in that every instance of a group with fields can have its
>> own text for those fields if the sharedText property is set to false,
>> and that behaviour could be expanded to almost all other properties.
>
>I'm not seriously proposing this, but I suppose we ought to at least
>consider something like a "sharedScript" property that could be set to
>false, in which case the script could be different on each card.
And "sharedColor" (which is in addition to the group inheriting its
colors from the stack and the objects in the group inheriting from
the group), and "sharedTextStyle", and "sharedToolTip", and, and, and
... I think the idea of a "living template" is easier to grasp.
>This is independent of being able to assign a "parent" object that
>the messages would go through before the regular hierarchy. But the
>two could be used together to do what you want.
So we have at least two new and unrelated concepts that do part of
what one supposedly natural concept could do, that already is used
all over xTalk?
At 23:46 Uhr -0400 23.09.1999, Raymond E. Griffith wrote:
> > As for putting the same object on a card multiple times, a "viewer"
>> object has often been proposed. A group (or possibly a stack or card
>> or even maybe any other object type) could be assigned to appear in
>> one of these, and it would be up to the "viewer" to keep track of what
>> data was associated with the group/card/stack at that particular
>> place.
>
>Please don't. At least, please don't if this will be anything like
>ToolBook's viewer object.
Viewer objects are still another thing and TB is not a very good
thing to get ideas from. 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).
>But classes seem to me to be similar to multi-dimensional arrays.
>
>>> >> get the emailAddress of user "Scott"
>
>might be able to be handled in array notation and retrieved by a function or
>handler. Perhaps a physical object, such as a button or a field could have a
>custom object reference. This CustomObjRef property could be shared with
>many objects and differentiated by the name of the object. So instead of
>saying
>
>get the emailAddress of fld "Scott",
>
>we could set the CustomObjRef of fld "Scott" to "user", then ask
>
>get the emailAddress of user "Scott".
Cool! But just rename the customObjRef property to "class" and you
are where I wanted to go.
>I recall reading something on the MetaCard digest that one could set
>an object like a field or even a stack as the custom property of an
>object. if a field has custom properties, and that field is set as
>the custom property of another object, then a custom property has
>custom properties.
I think you have mixe things up here... you can set a custom property
to the contents of a field or the reference to a field, but not to
the field itself nor to a copy of the field.
>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.
What is a background if it is not placed anywhere? A class is not a
class because it has no physical representation, is it? I often
wanted to be able to edit the properties of the template controls
"physically". But I guess these are purely philosophical questions.
> > >> 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.
>Remember, one of the great strengths of MetaCard is the fact that
>every object has properties and can be scripted -- true OOP.
But only for premade object classes (yet)!!!
> > >More serious are things like object creation/deletion and
> > >garbage collection.
> > Memory management gets only a problem if there are references
> > But how can we make shure, the user object stays in memory or gets
>> removed from memory as soon as it is not referenced any more? I'd say
>> we can not, because there are too many ways to reference objects
>> without the engine knowing.
>
>Right. That's what garbage collection takes care of.
Even a garbage collection has to find out if there are still
references to an object. Consider:
put the id of user "Scott" into fld "current user"
and years later
get the emailAddress of user id (fld "current user")
If the user object is not persistent and reloaded, you must keep it
in memory forever!
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 |
--------------------------------------------------------------------
