Tim Rowe wrote:
... I like the second style because it makes it leaves the 2-d
implementation hidden, which is the whole point of encapsulation.
I like the second as well, in that it it allows the parent to update any
related data structures (for example, updating a display). However, I
am a bit nervous about changing the signature of the move message, and
would be more tempted to add a move3d, for multiple inheritance reasons.
But then I am a fan of Hungarian notation, which many
programmers can't stand.
Is it that programmers can't stand it, or is it that they can't stand
it when it's imposed when not needed? ....
Well, I tend to be one who hates Hungarian. I spent a long time being
a fan of strong typing. Then, I felt the compiler would enforce the
typing, and the Hungarian muddied the readability of the expressions.
I felt that you should define a type for distance_in_yards, and not have
that confusable with distance_in_meters (though you might provide an
automatic conversion.
Now, I feel strong-typing systems cannot express the type relationships
that I want as a programmer in the face of sub-typing, and I hold
no hope that (A) such a language will appear, or (B) that the strong
majority of the bugs I produce in Python will be caught by a statically
typed system. I do however, still find the neddling little text
annotations in the variable naming to be irritating noise that distracts
from the readability of the expressions.
The kinds of type systems that I want(ed) is most closely expressed by
F-Bounded polymorphism, and that doesn't manage to be both expressive
enough and computationally feasible to use as a production type system.
For example, I'd like to type a sort function or a project function,
and all I've seen looks like its fit will feel more like a suit of armor
than a shirt.
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
