I need to think about it some more. This whole proxy stuff is very cool
indeed, but I am concerned about the performance - a simple "get" method
will initiate a long chain of method calls.
Well... simple property introspection has the same flaw I guess (this was
one of the reasons CayenneDataObjects are done as HashMaps internally).
As far as Cayenne is concerned though, having an ability to look up an
arbitrary object in the object store via a static method is already more
than 50% of the implementation of "arbitrary class persistence", no matter
if we use proxies or just property introspection. So this is the way go
anyways.
Andrus
Magic Hat writes:
> Hello,
>
> On Monday, September 2, 2002, at 04:17 , Holger Hoffstätte wrote:
>
>> - Strings are evil! I beg you to please, PLEASE! change the APIs that
>> take
>> Strings as arguments to only use classes or proper Db/ObjEntities
>> whereever possible. For example:
>
> Well, I do have to agree with Holger that ""Strings are evil!"... And yes,
> a lot of them can be eliminated (eg class name and such)... Which leaves
> the crux of the problem untouched: attribute names. Which is kind of a
> bummer, because that leaves the entire KVC way of doing thing floating in
> the amorphic world of the untyped: no type information about method,
> parameter, return type, exceptions... Casting everywhere, every time.
> Duh...
>
> Which is, as pointed out, very counterproductive and error prone.
>
> On the other hand, generating before hand a bunch of classes simply to get
> proper methods and some place holder for ivars seems, well, not worth the
> trouble. Plus, it's ugly, cumbersome and inflexible.
>
> Ideally, I would like to see something that is both strongly typed,
> generic, and does not require any specific class hierarchy... :-) Which
> seems to be a tough one to crack in Java.
>
> Putting feasibility issues aside, here is a scenario I was thinking of
> trying to pursue to try to square is off...
>
> For example, an EO could access its data the following way:
>
> public class MyEO extends Object
> {
>
> public String name()
> {
> (1) ObjectStore aStore = ObjectStore.storeForObject( this );
> (2) MyEOI anInterface = (MyEOI) aStore.interfaceForObject( this );
>
> (3) return anInterface.name();
> }
>
> }
>
> (1) First, an EO get its object store.
>
> (2) Then, it asks for an interface to its data... instead of using KVC or
> relying on some imposed superclass implementation.
>
> (3) Finally, it simply ask the interface for a given value... Will all the
> benefit of a strongly typed method.
>
> The interface itself could be generated (urgh!) by the system during
> modelization and would mimic all the EO attributes properties:
>
> public interface MyEOI
> {
>
> public String name();
>
> }
>
> Now, the object store could provide a default implementation of the
> interface to retrieve data by using java.lang.reflect.Proxy. Something
> along the line of:
>
> public Object interfaceForObject(Object anObject)
> {
> InvocationHandler anHandler = new DataHandler( this, anObject );
> Class aClass = Class.forName( anInterfaceName );
> Object anInterface = Proxy.newProxyInstance
> ( aClass.getClassLoader(), new Class[] { aClass }, anHandler );
>
> return anInterface;
> }
>
> Now the InvocationHandler could be implemented in whichever way the
> ObjectStore see fit to retrieve any given data.
>
> To summarize:
>
> - The Modeler generates an *interface* to interact with an EO data.
>
> - The EO can be of any class.
>
> - To access its data, the EO would ask its ObjectStore for a "data"
> interface.
>
> - The ObjectStore will provide an interface implementation through the
> Proxy mechanism.
>
> Bottom line:
>
> - Only one *interface* get generated for each entity.
>
> - Only one cast necessary (from Object to a specific EO "data" interface).
>
> - Everything from then on is strongly typed.
>
> - No need for any artificially imposed class hierarchy.
>
> What do you think? Any thoughs, comments, criticisms are more than
> welcome!-)
>
> Cheers,
>
> PA.
This archive was generated by hypermail 2.0.0 : Tue Sep 03 2002 - 18:34:46 EDT