On Fri, 24 Sep 1999, Ruediger zu Dohna wrote:
> 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 would have to be more general than that. For example, if you
change the "parent's" font, objects "derived" from it would have to be
notified so that they could resize controls.
(We also need to work on terminology some here: I think what we're
talking about here is not really parent and child objects, nor is it
class and instance, nor is it really "inheritance").
> > > >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.
Probably, but I can still forsee a lot of confusion about what exactly
the result will be when the "template" is changed...
> >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?
No, it's just an extension of a general xTalk concept (messages pass
through "owner" objects), and a MetaCard concept (attributes like
fonts and colors are inherited from "owner" objects). All we'd be
doing is just adding objects to the heirarchy specified by name rather
than by structure (i.e., the current "owner" relationship).
> 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).
on menuPick newgroup, oldgroup
hide group oldgroup
show group newgroup
end menuPick
I don't see what's so hard about that. Can you edit the controls in
place in Serf? If not, how do you define the relationship between the
size of the stack (and the positions of the controls in it) and the
size of the space on a given tab?
> >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.
I think what he's referring to is the ability to put a whole stack's
file in a custom property, which you can then save to a file and open
like you would any other stack.
> >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.
Right. In pure OO language, a class is the description and any
physical (or at least visual) representation of it is an "instance".
You can't edit the class visually, only the instances. This whole
issue of what the "class" looks like and where it is stored is the
major hurdle we face because there is currently no concept like this
in any xTalk-based tool.
> > > >> 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.
I think this confuses the message heirarchy, which is constrained by
structure, from a class hierarchy, which wouldn't be (and which in
fact couldn't have any structure because it has no instances).
> >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)!!!
The CS terminology is "object based" as opposed to "object oriented".
> > > >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!
Exactly. The need to figure stuff like this out on the fly is why
garbage collection is slow, and why we want to avoid designs that rely
on it.
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...
