<devils-advocate>
They do need to specify something in the way of behavior. An iterface is the natural way, to do that in Java. Byte code enhancement or source generation is not required. As I understand it you are free to implement the PC interface by hand if you like. I suppose one could even imagine having a SuperClass that mostly implemented PC and could be extended and a few abstract methods overridden instead of implementing the Interface directly.
If they just describe the behavior of a persistant object in english then the spec will be denser and harder to read or if they arn't detailed enough we might wind up in debates about what the meaning of is is :). English is tricky stuff. Java is simpler :)
</devils-advocate>
Personally, enhancement seems a lot easier for me. I hope the OJB implementation will continue to use it when they develop their own standalone JDO in 2.0... either that or an xdoclet source enhancement. I can see how it isn't necessarily easier for people implementing the spec. As for bad practices, there's always a way to do it wrong :). Can I say.. java.lang.reflect... :)
- Gus
Brian McCallister wrote:
I call the requirement that any persistent class implement PersistenceCapable an evil part of the spec for the SPI as it is completely unnecessary. If a vendor chooses to use bytecode enhancement/generation/etc they are welcome to, but to require it as part of the spec is just annoying and encourages bad practices.
Anything obtainable from the PC interface is obtainable via the helper class, and that lets the behind-the-curtain stuff remain behind the curtain. Requiring the ability to cast to PC is a hack, and a hack in a spec not an implementation, which is worse.
-Brian
On Dec 9, 2003, at 2:45 PM, Gus Heck wrote:
The reason I expected to be wrong was that PC is listed as part of the SPI not the API. If applications muck around in the SPI then they may get information that is inconsistant with the same information provided by the API. The JDO vendor (OJB) may be doing fancy (and maybe even cool and useful) stuff you arn't supposed to see before giving it to you through the api, but accessing it through the SPI may short circuit the vendor's code. That is the theory as I understand it at least. Why is that evil?
- Gus
Brian McCallister wrote:
On Dec 9, 2003, at 2:04 PM, Gus Heck wrote:
Well I have discovered that my feeling that casting to PersistenceCapable was wrong is correct.
I prefer the term "evil" for this part of the spec ;-) (sorry Matt)
-Brian
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
