Andrus wrote:
> >deprecate this for b1 and have it call
> >
> > registerNewObject(DataObject dataObject)
> >
> >instead.
>
> +1 - this is exactly in the spirit of recent changes. If no one objects I
> will make this change.
done.
While I was doing this, I also saw createAndRegisterNewObject(String
objEntityName, and immediately had the urge to change it to have a Class
argument as well. Fortunately my feeble brain kicked in just in time and
told me that this might not be such a hot idea, because sometimes you
really need String-based Object creation without creating a typed package
dependency. Case in point: some of the tests still use
lookupObjEntity("Artist") since they don't (yet?) import the class, maybe
for good reason - maybe not. I need to take a closer look.
Another reason might be that the assumed mapping of Class to ObjEntity
might not always be true or desired. How likely are scenarios like you
could have with EOF's EOGenericRecord, where you really don't care about
the class but just want to use a dumb record?
Personally I favor the class-based approach but I can see that sometimes
you don't want to create typed package dependencies. I don't know if this
is just wishful thinking since every Java project I've seen so far has
turned into a big ball of dependencies sooner or later.
Thoughts? If we agree that createAndRegisterNewObject should take a Class
(or maybe a class name instead of the entity name?) I'll volunteer. I have
some company time to spend on cayenne. ;)
-h
This archive was generated by hypermail 2.0.0 : Sun Nov 17 2002 - 07:56:18 EST