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.
> >
> >Now you've lost me. This seems to confuse attribute inheritance with
> >some other kind of inheritance. Being able to inherit things like
> >colors or fonts or even handlers (via the message path) would be
> >straightforward enough, but inheriting composite objects would be
> >quite a different thing.
>
> I am very well aware that this is much more to ask and I am not shure
> if and when this should be built in. Non-controll classes are by far
> the most important thing to me. But maybe an example may show better
> what this thing is meant to do:
> Consider a database frontend where every field that shows an
> attribute of a record should have the same look-and-feel. The field
> has a visible name; clicking in the field with the right mouse button
> shows a common behaviour; etc. It would be nice to create one group
> as a class "databaseField" or "dbFld" that looks like a template for
> the objects we want to create: It has two fields, one trasparent and
> attatched to the top of the other. All other properties are left as
> an exercise to the reader ;)
>
> create dbFld "customer_id"
> creates an instance of the class.
>
> set the title of dbFld "customer_id" to "Customer"
> Sends the setProp message to the object itself that does not handle
> the message so it passes up to the class object (the group) where a
> script puts the value into the header field.
>
> 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...
> >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. 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.
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.
> > > Coming to the
> >> question of where to store these classes, it may be an option to only
> >> allow backgrounds to act as custom controls, because there is a way
> >> to store and still edit them.
> >
> >This question applies to the other kinds of controls as well: should
> >the "classes" be just a particular instance of an object, or a truly
> >abstract collection of property/value pairs? The former is how
> >ToolBook does it and is more xTalk like, while the latter is more like
> >real OO languages but would probably be harder to learn.
>
> What I wanted to say was that groups can live in a stack without
> being visible anywhere, and still there is a intuitive way to edit
> them (place, edit, remove). This is exactly what custom classes need
> as well. The idea I had was that in order to create a custom field,
> it would have to be grouped (with itself only).
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 I would like to see much more than all of this, are non-control
> >> objects and classes. I think it would be nice to say:
> >>
> >> get the emailAddress of user "Scott"
> >>
> >> These objects could either live temporarily in memory or be stored as
> > > custom properties et.al.!
> >
> >There are a huge number of issue associated with this kind of true OO
> >system. Persistence (where are these objects stored?) is just one of
> >them. More serious are things like object creation/deletion and
> >garbage collection. I think we can learn from the mistakes of the
> >designers of JavaScript here, who went half-way down this road and
> >stopped, the result being a very confusing morass of metaphors that
> >most people have a serious problem getting their heads around.
>
> I am shure we can figure out those details... I can suggest
> something, but I know, you will find an even better solution (as you
> repeatedly did).
>
> 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
> 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 |
> --------------------------------------------------------------------
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
