[OT] JDO spec evil?

[Gus Heck <gu...@olin.edu>]

Ah, I see your point now... playing devils advocate and straying off 
topic for a moment...

<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: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org