interface question: what should return a transformation method?

S

Stefano Sabatini

Hi all,

for a transformation method I mean a method which will transform an
object changing its internal state.

Do you think it is a good idea to return the pointer to the modified object like this:
Object* Object::transform()
?

In this way it is possible to combine different transformation methods
to get the very convenient and compact notation:

obj.stretch().munge().dilate().colorize();

On the other hand, the Java standard library and some C++ libraries
(e.g. libpt) seem to prefer to return a boolean (true in case of a
successful operation).

Any thoughts? Many thanks in advance.
 
V

Victor Bazarov

Stefano said:
for a transformation method I mean a method which will transform an
object changing its internal state.

Do you think it is a good idea to return the pointer to the modified
object like this: Object* Object::transform()
?

A reference to it is probably better.
In this way it is possible to combine different transformation methods
to get the very convenient and compact notation:

obj.stretch().munge().dilate().colorize();

No, if you return a pointer, you will need to use ->:

obj.stretch()->munge()...
On the other hand, the Java standard library and some C++ libraries
(e.g. libpt) seem to prefer to return a boolean (true in case of a
successful operation).

It is impossible to tell without the context. If the operation *can*
fail, and you *do want* not to proceed with 'munge' after the failed
'stretch', then you shouldn't chain them, you should instead do

if (obj.stretch() && obj.munge() && ...)

which will short-circuit and return false from the first operation
that doesn't finish "correctly". If you need to know which operation
failed, you need to wrap each in its own 'if'.

V
 
S

Stefano Sabatini

A reference to it is probably better.


No, if you return a pointer, you will need to use ->:

obj.stretch()->munge()...


It is impossible to tell without the context. If the operation *can*
fail, and you *do want* not to proceed with 'munge' after the failed
'stretch', then you shouldn't chain them, you should instead do

if (obj.stretch() && obj.munge() && ...)

which will short-circuit and return false from the first operation
that doesn't finish "correctly". If you need to know which operation
failed, you need to wrap each in its own 'if'.

Mmh... yes it makes perfect sense, only now I wonder how the C++ exception
handling mechanism would handle such a thing (that is if
try {
obj.stretch().munge().dilate().colorize();
} catch (StretchingException) {
...
} catch (MungingException() {
...
} ...
}
would work).

But that is clearly another question.

Thanks for your reply Victor!
Regards.
 
J

James Kanze

On 2007-12-13, Victor Bazarov <[email protected]> wrote:

[...]
Mmh... yes it makes perfect sense, only now I wonder how the C++ exception
handling mechanism would handle such a thing (that is if
try {
obj.stretch().munge().dilate().colorize();
} catch (StretchingException) {
...
} catch (MungingException() {
...
} ...}
would work).

Why shouldn't it. An exception interupts the expression being
evaluated. Whether it is an appropriate solution or not depends
on a number of other factors, in particular, what types of
failure are you expecting.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top