How to pass class instance to a method?
d at davea.name
Tue Nov 27 06:18:55 CET 2012
On 11/26/2012 11:10 PM, Steven D'Aprano wrote:
> On Mon, 26 Nov 2012 22:14:59 -0500, Dave Angel wrote:
>> On 11/26/2012 05:18 PM, Steven D'Aprano wrote:
>>> On Mon, 26 Nov 2012 16:58:47 -0500, Dave Angel wrote:
>>>> In a statically typed language, the valid types are directly implied
>>>> by the function parameter declarations, while in a dynamic language,
>>>> they're defined in the documentation, and only enforced (if at all) by
>>>> the body of the function.
>>> Well that certainly can't be true, because you can write functions
>>> without *any* documentation at all, and hence no defined type
>>> restrictions that could be enforced:
>> That's backwards. Any body should be a bug in that case. It doesn't
>> matter what you pass to a function that is unspecified, it's behavior is
>> undefined. Calling it is inherently illegal.
> Have you ever programmed before? *wink*
I think you know the answer to that. But for anyone else, I've been in
various aspects of software development for 42 years, longer if you
count various projects which were not turned into products. And the
approximately dozen patents were nearly all for things which shipped,
not just theoretical concepts.
> Seriously, as much as we would like to have full documentation of every
> piece of code before it is written, such a thing is awfully heavyweight
> for all but the biggest projects.
> In practice, many functions never get documented at all, or only
> partially documented. Whether this is a good thing or not, it is a fact,
> and no mainstream language *requires* you to write documentation, nor is
> the documentation is used to determine runtime behaviour. If it did, it
> would be code, not documentation.
> In lightweight or agile software development methodologies ("Bingo!") or
> exploratory development, you often write the code before you know what it
> does, or even what you want it to do. E.g. I'll sometimes have a vague
> idea of what I want a function or method to do, and go through three or
> four iterations of writing code before it is stable enough to begin
> documenting it.
> Given the practical reality that documentation is often neglected, there
> is a school of thought that says that *code* is the One True source of
> information about what the code does, that documentation is at best a
> hint or at worst completely redundant. While I think that's a bit
> extreme, I can see the point. If function f() puts the cat on the mat,
> but is documented as putting the hat on the cat, how do you know whether
> the documentation is wrong or the code?
Yes, and yes. They're both wrong. Function f() is just broken.
Especially it's name.
I know all that, and wasn't trying to pretend that documentation is
always or even frequently, adequate. But the bulk of this part of the
thread has been dealing with a function call, contrasting static typing,
where some work is done by the compiler, and dynamic typing, where
supposedly something is done by the interpreter. And I claim that the
interpreter cannot in general do anything at the call target, except
count the number of the arguments (maybe) and check the keywords. So
the only thing that can be done there is manual - check the docs. If
they're not there, there's just no comparison with the static case. And
for a non-trivial function, or generally one which calls non-trivial
functions, exhaustively analyzing the code of the function, and of the
function it calls, is impractical. So people just call the function and
Static typing isn't nearly enough, and therefore the feeling of security
it gives many is dangerously misleading. There have been (and
presumably still are) languages which allow subsets of types to be
explicitly declared, for example the type is int, but the restriction is
nonnegative int (eg. square root). Or the type is int, but the
restriction is between 4 and 7. Or the parameters have an
interrelationship, or a dependency on the system state: e.g. if the
first parameter is a string, then the second one must be one of 8
>>> Please, everybody, before replying to this thread, please read this:
>> I read part of it, and it's more than I care to read tonight. It seems
>> to be written by an anonymous person. By jumping around in his blog, I
>> see a lot of interesting articles, but i haven't yet figured out who he
>> is. Does he have a name? A degree, a job in computers, a reputation?
> Does it matter? Surely what he says should stand or fail on its own
> merits, not by who he is.
Yes, but since it's very hard slugging at first, I was curious if it
would be worth it. He uses a number of terms in ways foreign to my
background, and while I admire Humpty-Dumpty-ism, it certainly slows
down comprehension. Anyway, he's apparently got a reputation with you,
and that alone should make it worth the trouble. Just not tonight.
> He has a name, although it seems to be hard to find on his current blog:
> Chris Smith. As for the rest, I don't know.
One of the brightest people I've ever known is named Smith. But come to
think of it, that's a pretty common surname.
More information about the Python-list