Igor,
Thank you for your elaborated response. I think the examples you gave me
are valid for statically-typed languages only. At least not for Python.
If we add an extra parameter to key-value operation, we just add it to a
given API function as a named argument (“keyword argument” or “kwarg”)
with a sensible default value, so all the dependent code will run as it
did before the change, implicitly using the new default value. The newly
written code, in turn, will be able to take an advantage of the new
parameter by setting it explicitly. This behavior may be impossible in
Java or C++ without some additional abstraction layer for isolating
caller-supplied parameters from actually used ones. But for any
correctly written Python code such isolation level is only superfluous
and misleading.
The same thing is with the second example. If we stop using a string or
integer values as a cache identifiers and replace them with, say, floats
or objects, still no dependent code modification is required, taken that
the new cache identifiers remain unique and hashable in Pythonic sense
(i. e. it should be easy to test them for non-equality), that is only
natural for an identifier. All the existing code will continue to work
without hassle.
The above said is yet more relevant to the end user code, since my API
atm is mostly single-levelled and has very few internal codependencies
to maintain.
On 07/25/2018 08:00 PM, Igor Sapego wrote:
Dmitriy,
To me it seems that procedural approach makes it harder to maintaine
code and add new features. For example, imagine that we are adding
new feature for a thin client, and now we need to pass one more cache
parameter when doing any key-value operation, such as put. In your
approach, you will need to rewrite all the Cache API, adding new
argument to all the functions.
To give you another example, it is possible, that in future we will change
the way cache is identified, so the "hash" argument will become
deprecated in your approach.
To put it simple, procedural approach lacks encapsulation, which is
extremely important when you write library code and want to maintain
backward compatibility. It removes the separation between public API,
which we should not change from version to version, and private code,
which we are free to change whenever and however we want.
Best Regards,
Igor
