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]
