On Thu, 30 Sep 1999, Kevin Miller wrote:
> On Thursday, Sept 30 1999, M. Uli Kusterer wrote:
> > why don't we implement classes like icons are implemented in MC? I mean,
> > usually you have a separate card or stack with lots of graphics on it,
> > which are then used by buttons as their icons. Couldn't we simply say you
> > can use *any* object as a "base class" for another one?
> >
> > We could allow creating an object based on another one. This object would
> > have empty scripts etc., and passing a handler in this script would call
> > the handler in the object it's based on. Every object would get an
> > additional "basePart" property which is the equivalent to the "owner", and
> > maybe a list of "children" that are based on it.
> >
> > It seems simple and a bit awkward at first, but it's simple, logical and
> > powerful at the same time. Some examples:
> >
> > create button "OK" based on btn "defaultButton" of stack "My Templates"
> >
> > put the basePart of btn "OK" --> btn "defaultButton" of stack "My Templates"
> >
> > The message-passing path would be a bit watered-down, though:
> >
> > cd btn 5 -> basePart of cd btn 5 -> btn 5's card -> btn 5's stack -> btn
> > 5's mainStack
>
> This is starting to sound like an xTalk idea I can get my head around!
>
> So basically, an object could have the name of another object to inherit
> from, and would inherit any values that weren't set on that object? That
> could actually be quite useful, and useable, allowing shared scripts and
> sets of attributes, all changeable from a single object except where set on
> the instances.
>
> It does raise a few questions though. Wouldn't it be *very* hard to
> implement as the engine would need to know which properties had actually
> been set on an object, and which were at their default values or had been
> emptied?
It wouldn't be *very* hard, but there certainly are performance and
file-size issues associated with doing something like this. Part of
this problem has already been solved, as we've digested a list of
properties that could potentially be inherited which is returned by
the "properties" property in 2.3. But even that includes stuff that's
probably not useful (e.g., would you really want to be able to inherit
the rect of an object?)
> Also, what about groups? A useful way of implementing a common "control"
> would be to be able to place multiple objects together in a group and place
> that onto multiple stacks. One example might be to use this to script a
> standard list view that gets used throughout stacks. You'd create a generic
> view with scripts, and each placement of the group would have individual
> properties set on each object at will. So you could alter the rect, color,
> text and one or two specific script attributes of some of the objects, but
> everything else could be left to pass on up to the "master objects" level
> above. But this idea doesn't quite fit in with your original one, because
> "placing" a group in the traditional sense would place the whole original
> group, and making changes to it anywhere its placed would change *all*
> instances.
Right. But I'm still not really comfortable with this idea of
inheriting child objects in the same way that you can inherit scripts
or other properties.
> Which brings about an idea. How about implementing this by creating a way
> to "uncouple" a placed group from some other "master" instance of the group.
> All objects in that group would be the same as those objects in the master
> group, except if you set individual properties inside the instance, when
> you'd only end up with the properties of the objects in that instance of the
> group being affected.
I'm starting to think that a script-only solution to this problem is
the way to go. For example, you'd create a group and tell it to
inherit from some other "template" object. The script of that
template object would look at the children of the new group, and make
whatever adjustments were required (adding controls, moving them
around, etc). Then it would set a timestamp (version number) on the
"derived" group. Then the user could make whatever changes would be
required to customize the new group. If they later change the
"template" group, it would use its timestamp to update the groups
derived from it as needed to reflect it's new configuration (hopefully
without screwing up the users changes to those customized derived
versions). This makes for a larger burden on the "template"
developer, but seems the only way to build in enough flexibility to
handle the wide range of things this might be used for.
> > since here a button in a completely different stack would be inserted into
> > the path, and it could get messy determining who should receive messages
> > sent by a button's base part when the button was clicked. Should it arrive
> > at btn 5's card, or should it arrive at the basePart's card, or should it
> > arrive at one first, and if it isn't caught move on to the other one? This
> > could be a problem similar to HyperCard's dynamic message path.
>
> To keep things simple, I'd make *everything* work in the context of the
> current placement. If you place an object and it has an inherited script,
> it runs as if the object is in the placement. If you place a group, the
> entire group complete with group script operates in the context of the
> current placement.
This doesn't really solve the problem of using the same group multiple
places on the same card, though, does it?
Regards,
Scott
> Kevin
>
> > Cheers,
> > -- M. Uli Kusterer
> >
> > ------------------------------------------------------------
> > http://www.weblayout.com/witness
> > 'The Witnesses of TeachText are everywhere...'
> >
> > --- HELP SAVE HYPERCARD: ---
> > Details at: http://www.hyperactivesw.com/SaveHC.html
> > Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
>
> Kevin Miller <[EMAIL PROTECTED]> <http://www.xworlds.com/>
> Cross Worlds Computing, MetaCard Distributors, Custom Development.
> Tel: +44 (0)131 672 2909. Fax: +44 (0)1639 830 707.
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
