Pete, Graham,

Thanks for that. I'll make those changes today.

Andy.


On 7/17/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
Andy, I guess you are clear to go ahead and make those changes.

Cheers,

On 17/07/07, Graham Charters <[EMAIL PROTECTED]> wrote:
> Hi Pete, sounds good to me.
>
> On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > Graham,
> >
> > so if we move these methods to DataObjectImpl you should still be able
> > to use them by casting your DataObjectPtr to the impl? I think we
> > should do this in SDO HEAD along with the other 2.1 spec changes.
> > There should be only a small amount of rework required when you move
> > the PHP code up to use a 2.1 spec SDO.
> >
> > Cheers,
> >
> > On 17/07/07, Graham Charters <[EMAIL PROTECTED]> wrote:
> > > Hi Andy/Pete,
> > >
> > > Yes, we do use this method in the PHP SDO code - thanks for remembering 
us :-)
> > >
> > > I think we need to draw a distinction between SDO C++ for applications
> > > and SDO C++ as an embeddable library.  The SDO C++ spec covers the
> > > former and therefore does not talk about get/setUserData.  The library
> > > role of SDO C++ enables us to more easily write native SDO
> > > implementations for other languages (PHP, Ruby, etc...) and is IMO
> > > very important (I guess I would say that :-) ).
> > >
> > > Get/setUserData is used by SDO PHP to manage the relationship between
> > > the PHP SDO Objects and C++ SDO Objects.  Earlier versions of the PHP
> > > Extension tried to manage this separately, but this solution was
> > > complex and prone to problems.
> > >
> > > I hope this helps.
> > >
> > > Regards,
> > >
> > > Graham.
> > >
> > >
> > > On 17/07/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> > > > Andy, the static code generation was an old experiment and is not
> > > > used.I have been meaning to remove it for some time as it is confusing
> > > > being there.
> > > >
> > > > The get/setUserData was actually put in there at the request of the
> > > > PHP-SDO team. I'm not sure of the details but I think they use this to
> > > > maintain a correlation between the C++ SDO objects and PHP objects???
> > > > This code is not used anywhere within Tuscany SDO (or SCA) code.
> > > >
> > > > This may be a case where a real life application has shown up a
> > > > limitation in the spec and that we should take a proposal to the spec
> > > > group. I'll try and find out how essential this function is and if
> > > > there is another way to work around this to enable a spec compliant
> > > > api in Tuscany
> > > >
> > > > Cheers,
> > > >
> > > > On 17/07/07, Andy Grove <[EMAIL PROTECTED]> wrote:
> > > > > I'm currently looking at some of the issues that my collegaue, Michael
> > > > > Yoder, raised regarding the use of propietary methods in the SDO 
header
> > > > > files. In particular, I'm looking at the setUserData / getUserData
> > > > > methods in DataObject.h [TUSCANY-1370]. These methods could easily be
> > > > > moved to the DataObjectImpl.h header instead. The methods are only
> > > > > referenced in code generated static client code (generated by
> > > > > DataFactoryImpl::generateInterface).
> > > > >
> > > > > However, I'm nervous about making the change because the current 
sdotest
> > > > > suite does not excercise the static code generated classes enough to
> > > > > call these methods. For instance, if I change the code generator to 
call
> > > > > a non-existant method "foo" instead of getUserData or setUserData then
> > > > > the current tests still pass.
> > > > >
> > > > > What is the status of the code generator? The Tuscany web site
> > > > > (http://incubator.apache.org/tuscany/sdo-cpp-faq.html) states that 
there
> > > > > are no plans to support this feature. Is this correct?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Andy.
> > > > >
> > > >
> > > >
> > > > --
> > > > Pete
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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]
> > >
> > >
> >
> >
> > --
> > Pete
> >
> > ---------------------------------------------------------------------
> > 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]
>
>


--
Pete

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Thanks,

Andy.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to