"Strings are evil!"

From: Magic Hat (magic_ha..ac.com)
Date: Tue Sep 03 2002 - 05:43:12 EDT

  • Next message: Andrus Adamchik: "Re: cayenne-cvs vs. eclipse"

    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 - 05:43:07 EDT