You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Alan Conway (JIRA)" <qp...@incubator.apache.org> on 2007/02/01 21:07:05 UTC
[jira] Created: (QPID-342) Imrpove C++ client API
Imrpove C++ client API
----------------------
Key: QPID-342
URL: https://issues.apache.org/jira/browse/QPID-342
Project: Qpid
Issue Type: Improvement
Components: C++ Client
Reporter: Alan Conway
Currently the C++ client API is like this:
Connection myConnection;
myConnection.open(...);
Channel myChannel;
myConnection.openChannel(myChannel);
myChannel.dostuff...
I would like to change it to be like this:
Connection::shared_ptr myConnection = Connection::open(...);
Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
myChannel->dostuff...
There are two problems with the current approach:
- constructor creates "lame" objects, need an open() call to make them
useful.
- Letting user call constructor directly means we can't change the
implementation class, whereas the second approach allows us to return
anything inheriting from the user-visible class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (QPID-342) Isolate C++ client API
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway closed QPID-342.
----------------------------
Resolution: Duplicate
The new API proposal covers the user-visible aspects of this issue. A separate JIRA can be raised for the binary-compatibility and protocol-version independence aspects.
> Isolate C++ client API
> ----------------------
>
> Key: QPID-342
> URL: https://issues.apache.org/jira/browse/QPID-342
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Alan Conway
> Fix For: M3
>
>
> Currently the C++ client API is like this:
> Connection myConnection;
> myConnection.open(...);
> Channel myChannel;
> myConnection.openChannel(myChannel);
> myChannel.dostuff...
> I would like to change it to be like this:
> Connection::shared_ptr myConnection = Connection::open(...);
> Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
> myChannel->dostuff...
> There are two problems with the current approach:
> - constructor creates "lame" objects, need an open() call to make them
> useful.
> - Letting user call constructor directly means we can't change the
> implementation class, whereas the second approach allows us to return
> anything inheriting from the user-visible class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-342) Imrpove C++ client API
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway updated QPID-342:
-----------------------------
Fix Version/s: M2
> Imrpove C++ client API
> ----------------------
>
> Key: QPID-342
> URL: https://issues.apache.org/jira/browse/QPID-342
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Alan Conway
> Fix For: M2
>
>
> Currently the C++ client API is like this:
> Connection myConnection;
> myConnection.open(...);
> Channel myChannel;
> myConnection.openChannel(myChannel);
> myChannel.dostuff...
> I would like to change it to be like this:
> Connection::shared_ptr myConnection = Connection::open(...);
> Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
> myChannel->dostuff...
> There are two problems with the current approach:
> - constructor creates "lame" objects, need an open() call to make them
> useful.
> - Letting user call constructor directly means we can't change the
> implementation class, whereas the second approach allows us to return
> anything inheriting from the user-visible class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (QPID-342) Imrpove C++ client API
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478094 ]
Alan Conway commented on QPID-342:
----------------------------------
We need to go a bit further and provide a full Pimpl client API to provide a binary compatibility safeguard. (http://en.wikipedia.org/wiki/Pimpl for definition of Pimpl) We should use shared_ptr to get normal copy semantics and automated memory management and templatize as much repetative code as possible.
> Imrpove C++ client API
> ----------------------
>
> Key: QPID-342
> URL: https://issues.apache.org/jira/browse/QPID-342
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Alan Conway
>
> Currently the C++ client API is like this:
> Connection myConnection;
> myConnection.open(...);
> Channel myChannel;
> myConnection.openChannel(myChannel);
> myChannel.dostuff...
> I would like to change it to be like this:
> Connection::shared_ptr myConnection = Connection::open(...);
> Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
> myChannel->dostuff...
> There are two problems with the current approach:
> - constructor creates "lame" objects, need an open() call to make them
> useful.
> - Letting user call constructor directly means we can't change the
> implementation class, whereas the second approach allows us to return
> anything inheriting from the user-visible class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-342) Isolate C++ client API
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway updated QPID-342:
-----------------------------
Summary: Isolate C++ client API (was: Imrpove C++ client API)
> Isolate C++ client API
> ----------------------
>
> Key: QPID-342
> URL: https://issues.apache.org/jira/browse/QPID-342
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Alan Conway
> Fix For: M3
>
>
> Currently the C++ client API is like this:
> Connection myConnection;
> myConnection.open(...);
> Channel myChannel;
> myConnection.openChannel(myChannel);
> myChannel.dostuff...
> I would like to change it to be like this:
> Connection::shared_ptr myConnection = Connection::open(...);
> Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
> myChannel->dostuff...
> There are two problems with the current approach:
> - constructor creates "lame" objects, need an open() call to make them
> useful.
> - Letting user call constructor directly means we can't change the
> implementation class, whereas the second approach allows us to return
> anything inheriting from the user-visible class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-342) Imrpove C++ client API
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway updated QPID-342:
-----------------------------
Fix Version/s: (was: M2)
M3
> Imrpove C++ client API
> ----------------------
>
> Key: QPID-342
> URL: https://issues.apache.org/jira/browse/QPID-342
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Alan Conway
> Fix For: M3
>
>
> Currently the C++ client API is like this:
> Connection myConnection;
> myConnection.open(...);
> Channel myChannel;
> myConnection.openChannel(myChannel);
> myChannel.dostuff...
> I would like to change it to be like this:
> Connection::shared_ptr myConnection = Connection::open(...);
> Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
> myChannel->dostuff...
> There are two problems with the current approach:
> - constructor creates "lame" objects, need an open() call to make them
> useful.
> - Letting user call constructor directly means we can't change the
> implementation class, whereas the second approach allows us to return
> anything inheriting from the user-visible class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-342) Isolate C++ client API
Posted by "Alan Conway (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan Conway updated QPID-342:
-----------------------------
Description:
(See API proposal in QPID-664)
Currently the C++ client API is like this:
Connection myConnection;
myConnection.open(...);
Channel myChannel;
myConnection.openChannel(myChannel);
myChannel.dostuff...
I would like to change it to be like this:
Connection::shared_ptr myConnection = Connection::open(...);
Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
myChannel->dostuff...
There are two problems with the current approach:
- constructor creates "lame" objects, need an open() call to make them
useful.
- Letting user call constructor directly means we can't change the
implementation class, whereas the second approach allows us to return
anything inheriting from the user-visible class.
was:
Currently the C++ client API is like this:
Connection myConnection;
myConnection.open(...);
Channel myChannel;
myConnection.openChannel(myChannel);
myChannel.dostuff...
I would like to change it to be like this:
Connection::shared_ptr myConnection = Connection::open(...);
Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
myChannel->dostuff...
There are two problems with the current approach:
- constructor creates "lame" objects, need an open() call to make them
useful.
- Letting user call constructor directly means we can't change the
implementation class, whereas the second approach allows us to return
anything inheriting from the user-visible class.
> Isolate C++ client API
> ----------------------
>
> Key: QPID-342
> URL: https://issues.apache.org/jira/browse/QPID-342
> Project: Qpid
> Issue Type: Improvement
> Components: C++ Client
> Reporter: Alan Conway
> Fix For: M3
>
>
> (See API proposal in QPID-664)
> Currently the C++ client API is like this:
> Connection myConnection;
> myConnection.open(...);
> Channel myChannel;
> myConnection.openChannel(myChannel);
> myChannel.dostuff...
> I would like to change it to be like this:
> Connection::shared_ptr myConnection = Connection::open(...);
> Channel::shared_ptr myChannel = myConnection->openChannel(...channel args);
> myChannel->dostuff...
> There are two problems with the current approach:
> - constructor creates "lame" objects, need an open() call to make them
> useful.
> - Letting user call constructor directly means we can't change the
> implementation class, whereas the second approach allows us to return
> anything inheriting from the user-visible class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.