GraphCopy, DigraphCopy parameter order

[Peter Kovacs]

Why do have the from, to order in the paramter list of GraphCopy, DigraphCopy and the related tools?

It seems really illogical for me, since (almost) all tools that makes copying, moving in any environment use the opposite order.

It is an important point of the API, so it should be clarified before relasing 1.0.

[Alpar Juttner]

Replying to kpeter:

Why do have the from, to order in the paramter list of GraphCopy, DigraphCopy and the related tools?

It seems really illogical for me, since (almost) all tools that makes copying, moving in any environment use the opposite order.

What do you mean by "(almost) all"? What tools are actually in your mind? The only ubiquitous similar tool I can recall now is strcpy() and it uses the same order. And so does operator=().

For me, it is much more problematic that the class interface and the functional one are called oppositely (GraphCopy, but copyGraph). Shouldn't they use the same name?

[Peter Kovacs]

Replying to alpar:

What do you mean by "(almost) all"? What tools are actually in your mind?

Never have I used strcpy(), memcpy() and such C/C++ tools, but I also find them very illogical. Maybe it is a mater of taste.

However all the other examples I can remember use the opposite order. E.g.

• cp, mv commands in linux, unix, DOS, Windows, VMS platforms
• svn checkout, copy, move; hg clone, copy, move
• string/file copying tools in Java, PHP, Delphi, Perl, Ruby, Erlang etc.
• and even std::copy(), std::copy_n()! (they actually have more than 2 parameters, but they use the from-to order)
• etc.

So this order seems to have much more examples than the opposite one. I think copying a graph (so copying big, complex structures of potentially different types) is more analogous to copying files than copying C/C++ strings, which is very close to memcpy().

For me, it is much more problematic that the class interface and the functional one are called oppositely (GraphCopy, but copyGraph). Shouldn't they use the same name?

It would be important and I can't see any reasons why not. I could never remember which is which. Which form do you prefer? copyGraph() or graphCopy()? I suggest the former one.

[Alpar Juttner]

Replying to kpeter:

So this order seems to have much more examples than the opposite one.

Well, this is purely a matter of taste and education. Thousands of people uses strcpy() and they are comfortable with it, including me. The rational behind it is to mimic the behavior of the assignment operator.

On the other hand I must admit, that I am also comfortable the shell command cp, and I won't be devastated by a change in the current API.

I just see no reason to do it.

[Peter Kovacs]

Replying to alpar:

The rational behind it is to mimic the behavior of the assignment operator.

I see.

On the other hand I must admit, that I am also comfortable the shell command cp, and I won't be devastated by a change in the current API.

Anybody else? What is your oppinion?

[Alpar Juttner]

Please do something with this ticket so that we can close it.

[Peter Kovacs]

I suggest renaming

• DigraphCopy --> CopyDigraph,
• GraphCopy --> CopyGraph.

Moreover I find it much better to use the from-to order for the graph copying tools, but Alpar also have reasons for the current concept.

Please help us deciding this question, which has a strong effect on the public API!

So please vote:

• copyDigraph(orig_graph, new_graph).run(); or
• copyDigraph(new_graph, orig_graph).run(); ?

[Peter Kovacs]

[fe86041c013c] renames the graph copying classes and contains many doc improvements in core.h.

[Peter Kovacs]

[8ab073e5c4f9] modifies the graph copying tools to use the from-to order.

Please tell me, whether you like it or not.

[Peter Kovacs]

[dc9e8d2c0df9] modifies the graph copying tools to use the from-to order, renames copyGraph() to graphCopy(), copyDigraph() to digraphCopy(), and contains doc improvements for core.h.

Since this renaming is supported, I suggest to apply only this patch, and the ticket can be closed.

[Alpar Juttner]

Replying to kpeter:

Since this renaming is supported, I suggest to apply only this patch, and the ticket can be closed.

Well done!