bindings: drop "get_" prefix of methods that start this way
commit53ec4e237deeeddbbf810ca5ff588697705bd63b
authorSven Verdoolaege <sven@cerebras.net>
Wed, 21 Nov 2018 09:14:05 +0000 (21 10:14 +0100)
committerSven Verdoolaege <sven@cerebras.net>
Wed, 5 Dec 2018 08:52:29 +0000 (5 09:52 +0100)
tree2a1d225f9e57692b6bd17c06d3b2f856354818d9
parent1daf53d6c3576e8cbd12265954a50b741f43f896
bindings: drop "get_" prefix of methods that start this way

In the C API, a "get" infix in the function name serves
as a reminder that the function does not consume ("take")
its argument(s).
In the C++ and Python bindings, there is no such concept,
so the (now) "get" prefix does not serve any purpose and
in fact introduces a distinction that is completely irrelevant
and can only lead to confusion.

Drop the "get_" prefix from all corresponding exported methods.
Unfortunately, such methods have been exported to the (Python) bindings
ever since isl-0.15-226-g30cd06c67 (export isl_schedule and
isl_schedule_node, Wed Oct 21 22:25:46 2015 +0200).
The original names (with "get_" prefix)  can therefore not be removed.
This commit therefore also introduces methods with the original names
that call the corresponding methods with the new names.
In order to keep the differences between the Python and the C++ bindings
as small as possible, the same is done in the C++ bindings.

Note that no distinction is made between functions that are already
exported and those that will be exported in future.
This means that newly exported "get" methods will also
be exported under two names.
It does not seem worth the effort to try and make such a distinction.
In fact, it would probably be confusing to have some "get" methods
exported twice and others only once.

An alternative to having one variant call the other would be
to simply generate the same method twice but using different names.
The current scheme makes is more obvious that the two methods
are identical.

Signed-off-by: Sven Verdoolaege <sven@cerebras.net>
interface/cpp.cc
interface/cpp.h
interface/generator.cc
interface/generator.h
interface/python.cc
interface/python.h