You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Ed Slattery (JIRA)" <tu...@ws.apache.org> on 2006/07/13 13:01:29 UTC
[jira] Created: (TUSCANY-547) Discriminated types
Discriminated types
-------------------
Key: TUSCANY-547
URL: http://issues.apache.org/jira/browse/TUSCANY-547
Project: Tuscany
Type: Improvement
Components: C++ SDO
Environment: all
Reporter: Ed Slattery
There are macros in the SDO code in data object, and lists/sequences to handle the many get/set/add/insert APIS for each type if data object. These are a pain to debug, and the conversion routines in TypeImpl are necessarity duplicased for each type of data object.
One suggested approach which appeals would be to define a content holder class, which would hold the value of any type of data object. By allowing it to be constructed from any incoming type, we could reduce the get/set methods to oneline methods which set up this generic blob, flag its original type, and pass it on to a generic setter/getter.
Similarly the conversion routines could query the current type of the blob, and perform the correct conversion for the blob to the requested type.
This would reduce the codebase, make it cleaner.
Also, we dont deal with XSD Unions at present, but having this blob in place, we could extend the flag saying what type it is, to be perhaps a bitmask saying what types if could be, and what type it is currently - this would make unions supportable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [jira] Updated: (TUSCANY-547) Discriminated types
Posted by Caroline Maynard <ca...@gmail.com>.
On 09/02/07, Caroline Maynard <ca...@gmail.com> wrote:
>
> Next, I'm seeing quite a few access violations. Investigating ...
After much fretting about reference-couting pointers, a completely clean
build sorted those out. I'm left with only one problem from running the PHP
tests, which is very impressive considering the scope of the updates. I'll
characterise the problem and report back.
--
Caroline
Re: [jira] Updated: (TUSCANY-547) Discriminated types
Posted by Caroline Maynard <ca...@gmail.com>.
On 08/02/07, Caroline Maynard <ce...@php.net> wrote:
>
>
> Geoff, sorry I hadn't responded to this sooner, but I was working on a
> release of SCA and SDO for PHP and didn't want to pick up your latest
> code at that point. The release is done now, so I'll give the new stuff
> a whirl and see how it goes. Looks like it's now in HEAD, right?
First trouble was that it didn't compile for me. I've raised
http://issues.apache.org/jira/browse/TUSCANY-1103 for this.
Next, I'm seeing quite a few access violations. Investigating ...
--
Caroline
Re: [jira] Updated: (TUSCANY-547) Discriminated types
Posted by Caroline Maynard <ce...@php.net>.
Geoff, sorry I hadn't responded to this sooner, but I was working on a
release of SCA and SDO for PHP and didn't want to pick up your latest
code at that point. The release is done now, so I'll give the new stuff
a whirl and see how it goes. Looks like it's now in HEAD, right?
Geoff Winn (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/TUSCANY-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Geoff Winn updated TUSCANY-547:
> -------------------------------
>
> Attachment: TUSCANY-SDOValue.patch
>
> The attached patch is a first draft of a sizeable revision of SDO to eliminate a good deal of macro code. This particular patch will not be applied to the repository (since it hasn't been tried on Linux yet, for example) but if anyone would like to try it then I'd appreciate the feedback.
> In theory the external behaviour of SDO hasn't changed. in practice there are bound to be a few places where things hav ealtered a bit, the areas most at risk are
> a) Exceptions thrown in case of problems may occur at different points, so from a users point of view may be thrown sooner or later than expected.
> b) Data conversions may not be identical.
> I'll fix any of these that we find.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-547) Discriminated types
Posted by "Geoff Winn (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Geoff Winn updated TUSCANY-547:
-------------------------------
Attachment: TUSCANY-SDOValue.patch
The attached patch is a first draft of a sizeable revision of SDO to eliminate a good deal of macro code. This particular patch will not be applied to the repository (since it hasn't been tried on Linux yet, for example) but if anyone would like to try it then I'd appreciate the feedback.
In theory the external behaviour of SDO hasn't changed. in practice there are bound to be a few places where things hav ealtered a bit, the areas most at risk are
a) Exceptions thrown in case of problems may occur at different points, so from a users point of view may be thrown sooner or later than expected.
b) Data conversions may not be identical.
I'll fix any of these that we find.
> Discriminated types
> -------------------
>
> Key: TUSCANY-547
> URL: https://issues.apache.org/jira/browse/TUSCANY-547
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Environment: all
> Reporter: Ed Slattery
> Fix For: Cpp-M3
>
> Attachments: TUSCANY-SDOValue.patch
>
>
> There are macros in the SDO code in data object, and lists/sequences to handle the many get/set/add/insert APIS for each type if data object. These are a pain to debug, and the conversion routines in TypeImpl are necessarity duplicased for each type of data object.
> One suggested approach which appeals would be to define a content holder class, which would hold the value of any type of data object. By allowing it to be constructed from any incoming type, we could reduce the get/set methods to oneline methods which set up this generic blob, flag its original type, and pass it on to a generic setter/getter.
> Similarly the conversion routines could query the current type of the blob, and perform the correct conversion for the blob to the requested type.
> This would reduce the codebase, make it cleaner.
> Also, we dont deal with XSD Unions at present, but having this blob in place, we could extend the flag saying what type it is, to be perhaps a bitmask saying what types if could be, and what type it is currently - this would make unions supportable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Commented: (TUSCANY-547) Discriminated types
Posted by "Geoff Winn (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-547?page=comments#action_12422591 ]
Geoff Winn commented on TUSCANY-547:
------------------------------------
I'm looking into this.
> Discriminated types
> -------------------
>
> Key: TUSCANY-547
> URL: http://issues.apache.org/jira/browse/TUSCANY-547
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Environment: all
> Reporter: Ed Slattery
>
> There are macros in the SDO code in data object, and lists/sequences to handle the many get/set/add/insert APIS for each type if data object. These are a pain to debug, and the conversion routines in TypeImpl are necessarity duplicased for each type of data object.
> One suggested approach which appeals would be to define a content holder class, which would hold the value of any type of data object. By allowing it to be constructed from any incoming type, we could reduce the get/set methods to oneline methods which set up this generic blob, flag its original type, and pass it on to a generic setter/getter.
> Similarly the conversion routines could query the current type of the blob, and perform the correct conversion for the blob to the requested type.
> This would reduce the codebase, make it cleaner.
> Also, we dont deal with XSD Unions at present, but having this blob in place, we could extend the flag saying what type it is, to be perhaps a bitmask saying what types if could be, and what type it is currently - this would make unions supportable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Resolved: (TUSCANY-547) Discriminated types
Posted by "Geoff Winn (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Geoff Winn resolved TUSCANY-547.
--------------------------------
Resolution: Fixed
Changes built and tested on XP and Linux
> Discriminated types
> -------------------
>
> Key: TUSCANY-547
> URL: https://issues.apache.org/jira/browse/TUSCANY-547
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Environment: all
> Reporter: Ed Slattery
> Fix For: Cpp-M3
>
> Attachments: TUSCANY-SDOValue.patch
>
>
> There are macros in the SDO code in data object, and lists/sequences to handle the many get/set/add/insert APIS for each type if data object. These are a pain to debug, and the conversion routines in TypeImpl are necessarity duplicased for each type of data object.
> One suggested approach which appeals would be to define a content holder class, which would hold the value of any type of data object. By allowing it to be constructed from any incoming type, we could reduce the get/set methods to oneline methods which set up this generic blob, flag its original type, and pass it on to a generic setter/getter.
> Similarly the conversion routines could query the current type of the blob, and perform the correct conversion for the blob to the requested type.
> This would reduce the codebase, make it cleaner.
> Also, we dont deal with XSD Unions at present, but having this blob in place, we could extend the flag saying what type it is, to be perhaps a bitmask saying what types if could be, and what type it is currently - this would make unions supportable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-547) Discriminated types
Posted by "ant elder (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-547?page=all ]
ant elder updated TUSCANY-547:
------------------------------
Fix Version/s: Cpp-current
Affects Version/s: Cpp-current
> Discriminated types
> -------------------
>
> Key: TUSCANY-547
> URL: http://issues.apache.org/jira/browse/TUSCANY-547
> Project: Tuscany
> Issue Type: Improvement
> Components: C++ SDO
> Affects Versions: Cpp-current
> Environment: all
> Reporter: Ed Slattery
> Fix For: Cpp-current
>
>
> There are macros in the SDO code in data object, and lists/sequences to handle the many get/set/add/insert APIS for each type if data object. These are a pain to debug, and the conversion routines in TypeImpl are necessarity duplicased for each type of data object.
> One suggested approach which appeals would be to define a content holder class, which would hold the value of any type of data object. By allowing it to be constructed from any incoming type, we could reduce the get/set methods to oneline methods which set up this generic blob, flag its original type, and pass it on to a generic setter/getter.
> Similarly the conversion routines could query the current type of the blob, and perform the correct conversion for the blob to the requested type.
> This would reduce the codebase, make it cleaner.
> Also, we dont deal with XSD Unions at present, but having this blob in place, we could extend the flag saying what type it is, to be perhaps a bitmask saying what types if could be, and what type it is currently - this would make unions supportable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org