NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/cplus/18236

Text File | 1992-12-21 | 3.4 KB | 76 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!munnari.oz.au!metro!extro.ucc.su.OZ.AU!maxtal
From: [e-mail] (John MAX Skaller)
Subject: Re: Give me safe C++
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: extro.ucc.su.oz.au
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sat, 19 Dec 1992 17:51:11 GMT
Lines: 63

In article <[e-mail]> [e-mail] (Harald Fuchs) writes:
>In article <[e-mail]>, [e-mail] (John MAX Skaller) writes:
>> Anyone else for nested functions? Against?
>
>I agree that they are sometimes quite handy, but I've never missed
>them. In the old days when I was a Modula-2 addict, I used them most
>of the time in a situation where I needed a function call in a
>specific context (which in turn can be expressed as a kind of
>"state"), and this is exactly what objects are for.
>
    You are perfectly correct that nested functions can be replaced
by members if one rewrites huge hunks of code.

    It is also possible to just use an ordinary function in many cases,
and pass it lots of parameters.

    Your argument is also one that would disallow all nested blocks.

    In the spirit of your argument, I suggest that functions
not be allowed to have more than one parameter,
or more than one local variable.
If somehow this seems to leave you with an object that is just
a subtly hidden subspace of 'global' data, you would be
correct.

    While I'm definitely not a structured programming fan,
there are times when functional decomposition is appropriate,
and data decomposition is not.

    Especially considering the C++ is not just an OO language,
there are times when nested functions are far and away superior
to using objects, and others when objects are more correct
but its just too much work to bother.

    In any case, I'd like the choice. While developing
a parser recently the function got too big to read,
I wanted to decompose it. Because of the amount of context,
I was *forced* to rewrite it in terms of objects.

    The rewrite took LONGER to do than the original code
took to develop, and it still doesnt work properly.
Yes, it is now much easier to manage, but nested functions would
have provided a better transition from procedural code
to object oriented code. In particular I have been forced
to bind my data structures and interfaces prematurely
into classes when I actually wanted rapid prototyping.

    CLOS as I understand it IMPLEMENTS OO by nested
functions, the object IS the local activation record,
the nested functions ARE the members of that record,
and the object persists because of Garbage Collection.

    Perhaps the moral of this story is that there is more
than one way to do OO, and more than one way to write a program,
C++ is supposedly a hybrid language, and often C is said
to be block structured. I just wish this were true, so
I'm repeating my call for the artifical restriction against
nested functions to be removed.
--
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         [e-mail]
    Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------