from module operator.py we have functional abstraction
def concat(a, b):
"Same as a + b, for a and b sequences."
if not hasattr(a, '__getitem__'):
msg = "'%s' object can't be concatenated" % type(a).__name__
raise TypeError(msg)
return a + b
to perform concatenation.
How do I know if I can call concat(‘xyz’, 4) ?
One way is to understand how a + b works, but this breaks abstraction.
Here I feel, programmer using concat() need to have control over type checking at static time so that programmer can resolve type check issue at static time.
Instead programmer has to wait for strong type check done by python at run time and learn that second parameter also expects string type.
One cannot expect standard docs to give such information.
In java, if a method has a signature Object concat(Object a, Object b), programmer using this method can make sure that arguments sent to these parameters are at least subclass of class Object, as every class is advised to have toString() method.
So, Can I say that, due to lack of control over type checking by a programmer at static time can lead to building bad abstractions? I treat concat(a, b) as a bad abstraction for above reasons.
Aucun commentaire:
Enregistrer un commentaire