Jonno <jonnojohn...@gmail.com> writes:
> Let's say the existing module provides a class RoboCom() which allows
> the user to communicate with robots (it doesn't).
Well, can you say what it *does* do? These hypotheticals aren't very
helpful; I don't know what inferences I'm safe to draw from the made-up
situation. What is it you're *actually* trying to allow the user to do?
> A command that can be sent to the humanoid robot might look like:
> 1. send_cmd("left_leg.knee.raise 1.1") # 1.1 being a height in units of m
> A command that can be sent to the canine robot might look like:
> 2. send_cmd("tail.wag 3") # where 3 = number of times to wag.
So, the robot (except it's not a robot, apparently) is controlled by a
textual command API (or is it? is that part true, or just hypothetical?)
If you're trying to wrap a command-line based API in an object-oriented
API, then you're going to have considerable impedance mismatch between
those APIs.
Your success will depend on a number of factors, such as: how frequently
can the command-line interface be expected to change; how much effective
control do you have over the design of the command-line interface; how
sane is the command-line interface design; etc.
I can't recommend much general advice beyond: don't expect to wrap a
command-line interface in an object-oriented interface without greatly
distorting one or the other or both. It may be possible to get a modicum
of success, but you should not expect it to be satisfactory.
Of course, if I knew what you're *actually* trying to program for, I
might be able to offer more specific advice.
> Does that help explain things better?
Not really. It's up to you if you want to be coy about your actual
requirements, but the quality of assistance you can expect will be
commensurately low.
--
\ “Two paradoxes are better than one; they may even suggest a |
`\ solution.” —Edward Teller |
_o__) |
Ben Finney
--
https://mail.python.org/mailman/listinfo/python-list
