[3898] in java-interest
Re: Comments about AWT, etc.
daemon@ATHENA.MIT.EDU (Gary Aitken)
Fri Dec 1 00:02:36 1995
Date: Thu, 30 Nov 1995 19:47:57 -0700
From: garya@village.org (Gary Aitken)
To: donpark@telewise.com (Don Park), java-interest@java.sun.com
In-Reply-To: <199511300314.TAA04572@gw.quake.net>
>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
