Board index » delphi » Procedure inside procedure help

Procedure inside procedure help

Hello all
Can I write procedure inside procedure (please give an example). What about
scope of variable....
Thank you for your help.
Nhuyen

http://www.zfree.co.nz

 

Re:Procedure inside procedure help


Don't do it - it is both pointless and a complication for people
reading your code.

From your previous postings, it does not look like a 'school
assignment' - so just think again - run one up for fun - but do not
write complicted 'release code'.

On 18 Aug 2001 23:58:20 +1200, "Nhuyen" <sonphu...@zfree.co.nz> wrote:

Quote

>Hello all
>Can I write procedure inside procedure (please give an example). What about
>scope of variable....
>Thank you for your help.
>Nhuyen

>http://www.zfree.co.nz

Re:Procedure inside procedure help


J French <je...@iss.u-net.com> schreef in berichtnieuws
3b7e6e7a.12237...@news.u-net.com...

Quote
> Don't do it - it is both pointless and a complication for people
> reading your code.

I disagree. ( but I'm not religious about it <g> )
Local procedures/functions _can_ dramatically simplify code.

{------------------}
function DoSomething( x,y,z,w: double ): double;
  {---------------------}
  procedure DoCalculation(Par:double)
  var
    Temp: double;
  begin
    Temp := BlahBlah(x,y,Par);
    <longwinding stuff here >
    Result := Blah;
  end;

var
  Temp: double;
begin
   if SomeCondition then
      Temp := DoCalculation(z)
    else
      Temp := DoCalculation(w);
    Result := Blah_2(Temp)
end;

-The main code in DoSomething() is crystal clear
-The{*word*152}details are all contained in 1 place in DoCalculation()

--
Regards,

Dirk Claessens
---------------------------------------------------------
http://www.claessens16.yucom.be
Attention: All spamshields raised; E-mails will bounce!
---------------------------------------------------------

Re:Procedure inside procedure help


On Sat, 18 Aug 2001 16:52:13 +0200, "Dirk Claessens"

Quote
<will.bou...@back.com> wrote:
>J French <je...@iss.u-net.com> schreef in berichtnieuws
>3b7e6e7a.12237...@news.u-net.com...
>> Don't do it - it is both pointless and a complication for people
>> reading your code.

>I disagree. ( but I'm not religious about it <g> )
>Local procedures/functions _can_ dramatically simplify code.

>{------------------}
>function DoSomething( x,y,z,w: double ): double;
>  {---------------------}
>  procedure DoCalculation(Par:double)
>  var
>    Temp: double;
>  begin
>    Temp := BlahBlah(x,y,Par);
>    <longwinding stuff here >
>    Result := Blah;
>  end;

>var
>  Temp: double;
>begin
>   if SomeCondition then
>      Temp := DoCalculation(z)
>    else
>      Temp := DoCalculation(w);
>    Result := Blah_2(Temp)
>end;

>-The main code in DoSomething() is crystal clear
>-The{*word*152}details are all contained in 1 place in DoCalculation()

But you can achieve that crystal clarity just as well by
using a separate DoCalculation function that's _not_ nested.

Which is not to say that nested functions are bad. But people
often think that calling a nested function will be faster,
and it often turns out that it's actually slower. The only
advantage I see is that it makes it clear that the inner
function is not used elsewhere. I tend to put the "inner"
function immediately before the function that's going to
use it, and make certain it's not included in the implementation
section...

Quote
>--
>Regards,

>Dirk Claessens
>---------------------------------------------------------
>http://www.claessens16.yucom.be
>Attention: All spamshields raised; E-mails will bounce!
>---------------------------------------------------------

David C. Ullrich

Re:Procedure inside procedure help


Im Artikel <3b7e5...@zfree.co.nz>, "Nhuyen" <sonphu...@zfree.co.nz> schreibt:

Quote
>Can I write procedure inside procedure (please give an example). What about
>scope of variable....

procedure Outer(param: integer);
var shared: integer;

  procedure Inner;
  begin
    shared := param; //both are visible and accessible
  end;

var nonshared: integer; //invisible in Inner

begin //body of Outer
  Inner;
  nonshared := shared;
end;

DoDi

Re:Procedure inside procedure help


David C. Ullrich <ullr...@math.okstate.edu> schreef in berichtnieuws
3b7fcb68.909...@nntp.sprynet.com...

Quote
> On Sat, 18 Aug 2001 16:52:13 +0200, "Dirk Claessens"
> <will.bou...@back.com> wrote:

> >J French <je...@iss.u-net.com> schreef in berichtnieuws
> >3b7e6e7a.12237...@news.u-net.com...
> >> Don't do it - it is both pointless and a complication for people
> >> reading your code.

> >I disagree. ( but I'm not religious about it <g> )
> >Local procedures/functions _can_ dramatically simplify code.
[snipped]
> The only advantage I see is that it makes it clear that the inner
> function is not used elsewhere.

Another advantage- if many parameters must be passed - is that the scope of
the inner procedure is the same as the outer procedure. I tried to emphasize
that in the example.
Of course, if the action of the inner procedure is very general ( say,
adding x to y and take the square root of the result ) it would be better to
place it somewhere in a library unit.

Regards - Dirk

Re:Procedure inside procedure help


Quote
In article <3b7e5...@zfree.co.nz>, "Nhuyen" <sonphu...@zfree.co.nz> writes:
>Hello all
>Can I write procedure inside procedure (please give an example). What about
>scope of variable....

Should be used only rarely, for multiple calls within the outer procedure,
access to procedure variables varies according to where placed,  and the
sub-procs should be heavily marked for clarity. As ...

procedure Outer(ParamA : integer);
// sub-proc start = = = = = = = = = = = = = = = = = = = = =
  procedure InnerOne(ParamB : string);
  begin
  // cannot access Var1 & Var2
  end;
// sub-proc finish= = = = = = = = = = = = = = = = = = = = =
var
  Var1 : integer;
  Var2 : string;
// sub-proc start = = = = = = = = = = = = = = = = = = = = =
  procedure InnerTwo(ParamC : string);
  begin
  // can access Var1 & Var2
  end;
// sub-proc finish= = = = = = = = = = = = = = = = = = = = =
begin
//
// main code of Outer()
//
end;

Alan Lloyd
alangll...@aol.com

Re:Procedure inside procedure help


I re-iterate my point (yes I know an oxymoron)

Just don't do it.

If you must pass huge numbers of parameters, then do it in a Type.

Unless of course you are writing 'write only' code.

On 19 Aug 2001 20:12:22 GMT, alangll...@aol.com (AlanGLLoyd) wrote:

Quote
>In article <3b7e5...@zfree.co.nz>, "Nhuyen" <sonphu...@zfree.co.nz> writes:

>>Hello all
>>Can I write procedure inside procedure (please give an example). What about
>>scope of variable....

>Should be used only rarely, for multiple calls within the outer procedure,
>access to procedure variables varies according to where placed,  and the
>sub-procs should be heavily marked for clarity. As ...

>procedure Outer(ParamA : integer);
>// sub-proc start = = = = = = = = = = = = = = = = = = = = =
>  procedure InnerOne(ParamB : string);
>  begin
>  // cannot access Var1 & Var2
>  end;
>// sub-proc finish= = = = = = = = = = = = = = = = = = = = =
>var
>  Var1 : integer;
>  Var2 : string;
>// sub-proc start = = = = = = = = = = = = = = = = = = = = =
>  procedure InnerTwo(ParamC : string);
>  begin
>  // can access Var1 & Var2
>  end;
>// sub-proc finish= = = = = = = = = = = = = = = = = = = = =
>begin
>//
>// main code of Outer()
>//
>end;

>Alan Lloyd
>alangll...@aol.com

Re:Procedure inside procedure help


On Sun, 19 Aug 2001 21:03:34 +0200, "Dirk Claessens"

Quote
<will.bou...@back.com> wrote:
>David C. Ullrich <ullr...@math.okstate.edu> schreef in berichtnieuws
>3b7fcb68.909...@nntp.sprynet.com...
>> On Sat, 18 Aug 2001 16:52:13 +0200, "Dirk Claessens"
>> <will.bou...@back.com> wrote:

>> >J French <je...@iss.u-net.com> schreef in berichtnieuws
>> >3b7e6e7a.12237...@news.u-net.com...
>> >> Don't do it - it is both pointless and a complication for people
>> >> reading your code.

>> >I disagree. ( but I'm not religious about it <g> )
>> >Local procedures/functions _can_ dramatically simplify code.
>[snipped]
>> The only advantage I see is that it makes it clear that the inner
>> function is not used elsewhere.

>Another advantage- if many parameters must be passed - is that the scope of
>the inner procedure is the same as the outer procedure. I tried to emphasize
>that in the example.

That's another aspect of it. How is it an advantange? (Try to
read that as an actual question, not an assertion that it's not
an adbatange...)

Quote
>Of course, if the action of the inner procedure is very general ( say,
>adding x to y and take the square root of the result ) it would be better to
>place it somewhere in a library unit.

>Regards - Dirk

David C. Ullrich

Re:Procedure inside procedure help


"AlanGLLoyd" <alangll...@aol.com> skrev i melding
news:20010819161222.22572.00002264@nso-fq.aol.com...

Quote
> In article <3b7e5...@zfree.co.nz>, "Nhuyen" <sonphu...@zfree.co.nz> writes:

> >Hello all
> >Can I write procedure inside procedure (please give an example). What
about
> >scope of variable....

> Should be used only rarely, for multiple calls within the outer procedure,
> access to procedure variables varies according to where placed,  and the
> sub-procs should be heavily marked for clarity. As ...

There are different reasons for using a subroutine - breaking up code to
increase readability or the more usual reason for placing a piece of code in
a routine: reuse.
I kind of wonder when I see subroutines are not concidered "good latin".
Routines contining subroutines are sometimes hard to read, but that's
normally more or less unavoidable (complex routines). I'd say: place it
locally whenever it seems like the simplest, most readable solution. When
such a routine has absolutely no meaning outside the calling routine, it'd
better be placed locally.

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorge@takethisaway_itte.no (remve the obvious)

Re:Procedure inside procedure help


"David C. Ullrich" <ullr...@math.okstate.edu> skrev i melding
news:3b810df6.410554@nntp.sprynet.com...

Quote
> On Sun, 19 Aug 2001 21:03:34 +0200, "Dirk Claessens"
> <will.bou...@back.com> wrote:
> >Another advantage- if many parameters must be passed - is that the scope
of
> >the inner procedure is the same as the outer procedure. I tried to
emphasize
> >that in the example.

> That's another aspect of it. How is it an advantange? (Try to
> read that as an actual question, not an assertion that it's not
> an adbatange...)

When quite a large stack is built, it's of course an advantage to be able to
access all the data without duplicating a lot of these data. It also saves
some typing....

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorge@takethisaway_itte.no (remve the obvious)

Re:Procedure inside procedure help


"J French" <je...@iss.u-net.com> skrev i melding
news:3b80d4f2.6598375@news.u-net.com...

Quote
> I re-iterate my point (yes I know an oxymoron)

> Just don't do it.

Redicolous. It's like declaring local variables as object fields or global
variables. Code that makes no sense elsewhere may very well be placed locally
for clarity. Remember, a routinde declared outside the calling routine is
callable from anywhere lower down in the unit. The routine shows up when
using Code Completion, for one.

I really wonder where this idea is coming from ?
--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorge@takethisaway_itte.no (remve the obvious)

Re:Procedure inside procedure help


On Mon, 20 Aug 2001 21:01:33 +0200, "Bj?rge S?ther"

Quote
<REMOVE_bsaether@THIS_online.no> wrote:
>"J French" <je...@iss.u-net.com> skrev i melding
>news:3b80d4f2.6598375@news.u-net.com...
>> I re-iterate my point (yes I know an oxymoron)

>> Just don't do it.

>Redicolous. It's like declaring local variables as object fields or global
>variables. Code that makes no sense elsewhere may very well be placed locally
>for clarity. Remember, a routinde declared outside the calling routine is
>callable from anywhere lower down in the unit. The routine shows up when
>using Code Completion, for one.

Ok, let's put it differently - one day, possibly six months, maybe six
years later, you or someone else will have to re-visit your code.

Let us assume that it is you - do you want to make life hard for
yourself ?  Or do you want to write simple, effective, straightforward
code ?

IMO nested procedures are a way of obscuring functionality.

Quote

>I really wonder where this idea is coming from ?
>--
>Bjoerge Saether
>Consultant / Developer
>http://www.itte.no
>Asker, Norway
>bjorge@takethisaway_itte.no (remve the obvious)

Re:Procedure inside procedure help


On Mon, 20 Aug 2001 20:54:40 +0200, "Bj?rge S?ther"

Quote
<REMOVE_bsaether@THIS_online.no> wrote:
>There are different reasons for using a subroutine - breaking up code to
>increase readability or the more usual reason for placing a piece of code in
>a routine: reuse.
>I kind of wonder when I see subroutines are not concidered "good latin".
>Routines contining subroutines are sometimes hard to read, but that's
>normally more or less unavoidable (complex routines). I'd say: place it
>locally whenever it seems like the simplest, most readable solution. When
>such a routine has absolutely no meaning outside the calling routine, it'd
>better be placed locally.

We are talking about *nested* subroutines - not subroutines in
general.
Quote
>--
>Bjoerge Saether
>Consultant / Developer
>http://www.itte.no
>Asker, Norway
>bjorge@takethisaway_itte.no (remve the obvious)

Re:Procedure inside procedure help


"J French" <je...@iss.u-net.com> skrev i melding
news:3b81e800.1586597@news.u-net.com...

Quote
> On Mon, 20 Aug 2001 21:01:33 +0200, "Bj?rge S?ther"
> <REMOVE_bsaether@THIS_online.no> wrote:

> >"J French" <je...@iss.u-net.com> skrev i melding
> >news:3b80d4f2.6598375@news.u-net.com...
> >> I re-iterate my point (yes I know an oxymoron)

> >> Just don't do it.

> >Redicolous. It's like declaring local variables as object fields or global
> >variables. Code that makes no sense elsewhere may very well be placed
locally
> >for clarity. Remember, a routinde declared outside the calling routine is
> >callable from anywhere lower down in the unit. The routine shows up when
> >using Code Completion, for one.
> Ok, let's put it differently - one day, possibly six months, maybe six
> years later, you or someone else will have to re-visit your code.

> Let us assume that it is you - do you want to make life hard for
> yourself ?  Or do you want to write simple, effective, straightforward
> code ?

What conciderations do you believe are the most important to me ? I'd tell
you - I sometimes put 10 lines of code in a local routine FOR CLARITY ONLY !
It's a way of "black-boxing" to me. It's local, and its "singular". Let noone
else see it.
I do of course understand that one can find example of horrible coding with
local routines. As long as they work, you'll not have to rewrite them for
reuse, a process normally piece by piece "shaping up" an application's code.
A big chance that "singular" code is of poorer quality than core
functionality. While every step that extracts the general parts of code into
reusable routines is a good one, I think abandoning local routines is simply
not a good piece of advice.

I came to think of a period in my country (around 1985-95) where the
"driving-schools" (don't know the English word for it) learning motorbike
candidats to use only the front brake. While everyone understands this in a
pedagogical perspective, it's absolutely no doubt that applying the rear brak
e appropriately reduces stopping distance with maybe 10-20%. It's mixing of
levels when you let people finish their driving education only having heard
the "newbie teaching version".
I get the same feeling when someone is trying to tell us local routines are
bad. It's just not right, even if I could tell a newbie not to do it "for
now".

Quote
> IMO nested procedures are a way of obscuring functionality.

> >I really wonder where this idea is coming from ?

I still wonder if this is down the same road as "don't use GoTo" or "don't
let a function create an object" - some model or theory abandoning local
routines ? I am self-thought (well, until I joined the NG's, at least), and
never learned the "right way". When I revisit code written 6 years ago, I do
of course find local routines that I today would place otherwhere, but
definately not all. A local routine is the self-explainatory way of giving a
certain piece of code the perfect scope. Passing references to large
structures of "unfinished" data to an external routine that *must not* be
used for anything but this special case is just not good programming practice
to me.

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorge@takethisaway_itte.no (remve the obvious)

Go to page: [1] [2]

Other Threads