David,
I've been down this path many times, and my current recommendation is
to just have some kind of type on the object that identifies it as one
or the other. I have a situation where I store the class name of a
'calculator' class in the EO, and then dynamically call static methods
on that class to do the heavy lifting.
Ken
On Feb 13, 2008, at 11:15 AM, Mike Schrag wrote:
I could just create a new object of the new class and delete the
existing one
yes
What is the best way to get WO to pickup the subclass change
immediately?
Or is this just a bad way of doing things?
yes
Inheritance hierarchy is to be treated like a PK -- It's an
unchanging attribute of an EO. In fact, it's actually part of the
EOGlobalID.
What you're describing is very similar to the Employee vs Manager
modeling problem. The general consensus is that when an Employee
becomes a Manager, it's not changing types, it's changing Roles, so
it's actually a Person=>Role, where Role is Manager or Employee and
you are just changing the relationship, not the intrinsic type.
You should consider type to be immutable for your own safety and the
safety of those around you. The correct way is to delete your old
class and make a new one, or maintain a relationship to (something
like) a NutrionValueCalculator that changes (if there is a lot of
other state in this object other than just this value).
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/kenlists%40anderhome.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
