COIN-OR::LEMON - Graph Library

Opened 10 years ago

Closed 10 years ago

#150 closed enhancement (fixed)

GraphCopy, DigraphCopy parameter order

Reported by: kpeter Owned by: kpeter
Priority: blocker Milestone: LEMON 1.0 release
Component: core Version: hg main
Keywords: Cc:
Revision id:

Description

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.

Attachments (3)

fe86041c013c.patch (51.3 KB) - added by kpeter 10 years ago.
from-to_8ab073e5c4f9.patch (15.3 KB) - added by kpeter 10 years ago.
dc9e8d2c0df9.patch (53.5 KB) - added by kpeter 10 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 in reply to: ↑ description ; follow-up: Changed 10 years ago by alpar

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?

comment:2 in reply to: ↑ 1 ; follow-up: Changed 10 years ago by kpeter

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.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 10 years ago by alpar

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.

comment:4 in reply to: ↑ 3 Changed 10 years ago by kpeter

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?

comment:5 Changed 10 years ago by alpar

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

comment:6 Changed 10 years ago by kpeter

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(); ?

comment:7 Changed 10 years ago by kpeter

  • Priority changed from major to blocker

comment:8 Changed 10 years ago by kpeter

  • Owner changed from alpar to kpeter
  • Status changed from new to assigned
  • Version set to hg main

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

Changed 10 years ago by kpeter

Changed 10 years ago by kpeter

comment:9 Changed 10 years ago by kpeter

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

Please tell me, whether you like it or not.

Changed 10 years ago by kpeter

comment:10 follow-up: Changed 10 years ago by kpeter

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

comment:11 in reply to: ↑ 10 Changed 10 years ago by alpar

  • Resolution set to fixed
  • Status changed from assigned to closed

Replying to kpeter:

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

Well done!

Note: See TracTickets for help on using tickets.