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.
Note that in the class script we need a reference to the instance. I
can see several syntax options for the above script:
1. set the rect of fld "header" of the target to ... wordy but clean
2. set the rect of my fld "header" to ... "me" is not the object
where the script is in.
3. set the rect of fld "header" to ... not very explicit
4. set the rect of this fld "header" to ...
>If you added a control to the "class" group, would it appear in
>every group that "inherited" from that group?
Definetely!
>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.
>Maybe combined with the ability to have a separate location each
>place it appears (kind of like having a "sharedPosition" property
>you could set to false).
Exactly... but the same idea could be applied to any property, even
the size! Scripts should be shared with additional scripts in each
instance that are further down in the messege path.
> > 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).
>There are also a lot of issues related to where and how that data is
>stored (attached to a stack? In a new kind of object? In a text
>file that's #included?)
Attatched to a stack. Maybe that stack even has to be "in 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.
Some ideas:
- The class recieves a message that allows it to load an object that
is not in memory.
- The class recieves a message when someone tries to delete an
object, so it can store it somewhere.
- Other ways to reference objects... but this applies to everything
else as well (get the name of the button whose hilite is true) and
brings up the question of multiple matches (which can also happen
with object names).
- Objects exist only in memory (they are not persistent), but there
is a textual representation of them that you can store anywhere (put
the textualRepresentation of table 34 into fld "foo")
>If it's stored as a custom property, what's so bad about the way
>you'd do this now:
>get emailaddress[Ruediger] of me
> or maybe
>get userdata[emailaddress, Ruediger] of me
1. It reads less nice (ok, I can live with that)
2. I can not attatch any script.
3. There can never be class inheritance, polymorphism, etc.
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 |
--------------------------------------------------------------------
