interface question: what should return a transformation method?

[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::transfo rm()
?

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

obj.stretch().m unge().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.
--
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)

[Victor Bazarov]

Re: interface question: what should return a transformation method?

Stefano Sabatini wrote:

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::transfo rm()
?

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().m unge().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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Stefano Sabatini]

Re: interface question: what should return a transformation method?

On 2007-12-13, Victor Bazarov <v.Abazarov@com Acast.netwrote:

Stefano Sabatini wrote:

>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::transfo rm()
>?

>
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'.

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().m unge().dilate() .colorize();
} catch (StretchingExce ption) {
...
} catch (MungingExcepti on() {
...
} ...
}
would work).

But that is clearly another question.

Thanks for your reply Victor!
Regards.
--
Stefano Sabatini
Linux user number 337176 (see http://counter.li.org)

[James Kanze]

Re: interface question: what should return a transformation method?

On Dec 13, 4:40 pm, Stefano Sabatini <stefano.sabat. ..@caos.org>
wrote:

On 2007-12-13, Victor Bazarov <v.Abaza...@com Acast.netwrote:

[...]

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().m unge().dilate() .colorize();
} catch (StretchingExce ption) {
...
} catch (MungingExcepti on() {
...
} ...}

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.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34