[3916] in java-interest
Re: Comments about AWT, etc.
daemon@ATHENA.MIT.EDU (Don Park)
Sat Dec 2 03:33:05 1995
Date: Thu, 30 Nov 1995 20:19:19 -0800 (PST)
To: garya@village.org (Gary Aitken)
From: donpark@telewise.com (Don Park)
Cc: java-interest@java.sun.com
Way to go Gary!
I have also used 'object-pocket' concept with great success in many of my
projects. Like you said, 4 bytes are all you need to add 'pockets' to
objects in which arbituary data and references can be stored. Rather than
dealing with hashvalue explicitly, I typically rely on string atoms and a
smart storge interface which adopts appropriate implementation strategy
depending on the efficiency/cost factor. Most objects' will have only a few
'stuff' in their pocket so a simple list will do. For 'bag-lady' objects,
more elaborate scheme is used. The smart interface decides at runtime to
switch from simple scheme to more complex ones when certain thresholds are
reached.
Regards,
Don Park
>>I would appreciate it if following features are added to Java class framework.
>>
>>1. Attribute support in Object or Component class.
>>
>>Attribute support consists of ability to get, set, and add attributes.
>>Beside the obvious uses for the feature, this could be the means to support
>>platform specific features like allowing Font objects to support 'underline'.
>>
>>2. Memento support in Object or Component class.
>>
>>Memento support allows other objects to efficiently associate information
>>with given object. For example, a view object can leave view specific
>>information with the model object so it can be streamed out.
>
>I would consider #2 the single most important thing that could be added.
>It should be added at the Object level, however, not at Component, since
>the capability is generally needed for any kind of object, including Class
>objects. Given #2, it is possible to make virtually any extension you want.
>(speaking from past experience)
>
>I would suggest something along the following lines:
>
> void attributeSet(
> String attributeName, // name of attribute to save
> Object obj) // object associated with attr
> void attributeSet(
> UniqueHash attributeKey, // String form converted to
> Object obj) // a unique hash value
>
> Object attributeGet(String attributeName, Object)
> Object attributeGet(UniqueHash attributeKey, Object)
>
> Boolean attributeExists(String attributeName)
> Boolean attributeExists(UniqueHash attributeKey)
>
> void attributeDelete(String attributeName)
> void attributeDelete(UniqueHash attributeKey)
>
>The reason for the UniqueHash version of the interface is that real world apps
>end up fetching and setting the same set of values frequently, and it is
*much*
>faster to use a 32 bit unique key. Unless you are dealing with persistent
>objects, the key need only be unique for the current invocation. One model of
>a hash mechanism is the Xlib resource quark mechanism, XrmStringToQuark and
>XrmQuarkToString. I don't know how well these would adapt to Unicode, but I
>would guess one could do it fairly easily. One would then want the following
>static method available for class Object:
>
> UniqueHash uniqueHash(String)
>
>The attributeExists methods may appear redundant, but are not. There are
>numerous (*lots*) of situations where an application only needs to "mark" an
>object somehow, so the Object argument is null, and one needs a way to
>determine the difference between a missing attribute and an attribute with no
>associated Object.
>
>The cost of adding the above functionality is very low -- 4 bytes per object,
>plus the storage needed when the functionality is actually used. It allows
for
>virtually unlimited extension, in the form of delegation, and maintains binary
>compatibility when doing so. Furthermore, it allows extension to Classes for
>which one does not have source.
>
>>That is all I can remember right now. I am not expecting any of this to be
>>implemented given the situation you guys are in (squeezed, pickled, and
>>stapled to the desk) but at least you guys have one more e-mail to forward
>>upstairs to ask for more resources :).
>
>If Sun agreed to include the above in the official release, I would be
happy to
>provide a first cut implementation to get it off the ground. Wouldn't be
>absolutely optimal in terms of the hash function, as I don't have the time to
>dig into StringToQuark, but it would be useable / shippable.
>
>Gary Aitken garya@village.org
>
>
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
