On Thu, 23 Sep 1999, Raymond E. Griffith wrote:
> 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?
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".
> > 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.
Can you be more specific about the shortcomings of the viewer object?
> 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.
You could pass arrays to handlers in 2.2.X, but in 2.3 you can also do
assignment (copy them). You can also now store a whole array as a
custom property set.
> > 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.
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...
Scott
> Regards,
>
> Raymond
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
