Is anybody coming from Pascal?
steve at lurking.demon.co.uk
Sun Jul 22 06:43:57 CEST 2001
On Sat, 21 Jul 2001 16:47:53 -0600, Paul Sidorsky <paulsid at home.com>
>I'm not an expert in object-oriented design, but nested functions seem
>kind of anti-OO too me. Can behaviours (methods) really have their own
>behaviours (nested functions), or does the behaviour (nested function)
>actually belong to the object (class)? And for non-OO use they seem
>completely unnecessary to me. About all they seem to do is keep the
>global namespace a bit less polluted, but that's going to happen in
>non-OO anyhow. But maybe I'm missing something...
Nested functions are handy, but not the kind of thing people can't
live without. Functions are often written not so much to be re-usable,
but to separate excess low level detail out of a higher level function
and make things more readable. If a function is never intended to be
called outside the context of another function, it makes sense to
limit its availability to that function. If it's not applicable to the
wider class, it shouldn't be available to the wider class. Hiding
internal details (whether you call it data hiding or whatever) is
certainly an important part of object orientation, but it's a much
older idea than OO and doing it on a per-function basis has also been
a useful facility in several non-OO imperative languages including
Pascal, Modula 2 and Ada.
Nested classes are supported in C++, so the idea of lower level
abstractions within higher level abstractions does exist within that
language too. And I believe that the GNU C/C++ compiler has optional
support for nested functions.
An important aspect of a function within a function is that it cannot
be called by other functions. Therefore, when you change the outer
function you can safely change the inner function in the knowledge
that nothing else will be broken - not even other member functions of
the same class. Most useful programs will need maintenance by people
other than those who wrote them at some point. Limiting the scope of
what you need to understand makes this easier. In some cases, it's the
only reason maintenance is possible at all.
I have to admit, though, that I've never needed a nested function in
>> I conclusion, and in reviewing this post, I seem to have been rambling a
>> bit (it's a bit late/early in the day) but I'd be interested to get a
>> response from anybody else who rates Mr Wirth, and in how any such people
>> finding the transition. I'd also be curious to hear from anybody who has
>> tried object Pascal.
>Object Pascal is okay. I don't have much experience with it, but
>personally I'd hate to have to learn object-oriented concepts on it. It
>shares the same problem with C++ as being an extension to an existing
>language, so the implementation of OO features is kind of glued on. I
>think it's better to pick up OO concepts on Python (or even Java) before
>trying Object Pascal.
Pythons object orientation was glued onto a pre-existing non-OO
version of the language as well ;-)
The definitive OO language is always supposed to be Smalltalk.
Certainly it was the first, and designed to be pure OO. I've never
used it myself, though.
>Anyhow, I hope you stick with Python. You'll get a lot of the
>convenience of Pascal merged with a cleaner and much more well-designed
Agreed. Remember, even Wirth didn't settle for Pascal - though that is
possibly unfair, as his other languages had different target users.
Pascal was only intended for teaching, though - like BASIC - to get
people used to imperative (and structured, in Pascals case)
programming before they moved on to programming larger applications in
languages suited for those tasks - at the time, that probably meant
Fortran (scientific), COBOL (business), Algol (?), CORAL (real time?)
and a few others.
More information about the Python-list