Scott,
> 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. 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.
Wouldn't this defeat the idea of groups as background objects?
>
> 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. I *really* don't like ToolBook, and I have to use
it at the moment (groan). Oh, it has some nifty stuff, but it also has the
most clutsy way of doing some things.
Concerning classes. I admit to being at the edge of understanding this
entire thread. Years ago I knew more than what I do now, and that went the
way of unused knowledge.
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".
Back to the notion of arrays. I know there was difficulty in passing array
objects in MetaCard 2.2x. I understand (though I haven't tried) that passing
arrays is possible in 2.3. If array *storage* is possible, then perhaps
multidimensional custom properties would be possible.
In fact, it may already be. 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. I still don't understand what I read there
(being something of a novice still), [*warning, read the following
carefully, otherwise be prepared to be as confused as the writer ;) *]
but 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.
Am I making any sense? I could just be rambling on in ignorance (and lack of
sleep) ....
>
> 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.
>
Which I think is best (again, from a complete novice's viewpoint). If we add
non-physical objects to the mix, it would be easy to mess things up.
>> > > What I would like to see much more than all of this, are non-control
>> >> objects and classes.
>> >> These objects could either live temporarily in memory or be stored as
>> > > custom properties et.al.!
I understand that each object has a place in the inheritance structure.
Background objects are able to intercept messages after the card, but before
the stack. Where would a non-physical object be placed in the inheritance
structure? Remember, one of the great strengths of MetaCard is the fact that
every object has properties and can be scripted -- true OOP.
>>
>> Memory management gets only a problem if there are references / pointers:
>> set the owner of table 34 to the id of user "Scott"
>> 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. Unfortunately a
> pretty huge performance hit goes along with that (although you'll here
> bogus denials of this from Java zealots).
> Regards,
> Scott
And if we can stay away from garbage production, we won't have to collect as
much or as often.
>
>> Regards
>> R�diger
Regards,
Raymond
