• Print

Author Topic: 'Local' Functions and Subs within Functions and Subs  (Read 439 times)

codeguy

  • Hero Member
  • *****
  • Posts: 3552
  • what the h3ll did i name that code?
    • stuff at dkm
    • Email
Re: 'Local' Functions and Subs within Functions and Subs
« Reply #15 on: October 06, 2011, 11:33:54 AM »
if ya don't wanna make the function universal, encapsulate its code in the sub and use its result:
Code: [Select]
sub ThisSubHasAFunction(a$,prepend$)
if left$(a$,1)=prepend$ then
p%=0
else
p%=1
end if
if p% then
   a$=prepend$+a$
else
   ps%=instr(a$,prepend$)
   if ps% then
      a$=left$(a$,ps%-1)+mid$(a$,ps%+len(prepend$))
   end if
end if
end sub
and ain't paradigms a nickel short of a quarter? ;D
http://denteddisk.forums-free.com/make-an-appointment-with-the-resident-code-guru-f34.html

kidfrommars

  • Full Member
  • ***
  • Posts: 215
    • C & Fortran Polyglot
Re: 'Local' Functions and Subs within Functions and Subs
« Reply #16 on: October 06, 2011, 04:49:40 PM »
NM

mcalkins

  • Hero Member
  • *****
  • Posts: 1269
    • qbasicmichael.com
    • Email
Re: 'Local' Functions and Subs within Functions and Subs
« Reply #17 on: October 06, 2011, 09:25:31 PM »
DeeBee, I take it that you are an object oriented programmer. That's fine. Is your background perhaps Pascal, Delphi, or Ada?

I am a procedural programmer. I think Clippy is too. I would venture that most QBASIC, QB, and QB64 programmers are probably procedural programmers. That is also fine.

There is nothing inferior or deficient in traditional procedural programming. Remember that the core Windows NT OS, as well as other OS kernels, are written in C, a procedural language. The Windows API is a procedural C interface, although there is a C++ OO wrapper, MFC. (gcc allows nested functions, but that's not part of the C89 standard. I don't know if the Linux kernel (which is gcc dependent) avails itself of it.)

I have gotten the impression from what others have written that object oriented programming tends to be less efficient than comparable procedural programming. Each has its strengths and weaknesses. OO can be more elegant, from a certain perspective. Some other perspective might prefer the efficiency and apparent simplicity of procedural. To each his own.

As an Assembly programmer, I see nothing inherently wrong with either GOTO or GOSUB. It's true that GOTO is often used in very inelegant ways by new programmers. However, even that wouldn't apply to GOSUB. You can have your nested functions, I'll have my GOSUBs. You're free to have the opinion that my code is sloppy, but it is only your opinion. You'll have your opinions, I'll have my own opinions, Clippy will have his own, and everyone else will have their own. Back when I was in the fire department, my chief once said: "Opinions are like @$$holes, everyone has one."

Really, what's the practical difference between nesting a function, and combining GOSUB with a little creative variable naming? I don't think the GOSUB would be any less efficient. I am inclined to think that it would be more efficient. It would only require a fuzz more effort on the programmer's part to keep the variables straight. Or, if you use a second public function, with creative naming like I mentioned earlier, passing some of the first function's local variables as parameters to the second, it probably won't be much, if any, less efficient than nesting a function, and again, only requires a fuzz more effort on the programmers part (a slightly longer function name, and 1 more function declaration to clutter the source). Accidentally calling the creatively named second function from somewhere other than the first shouldn't even be an issue. You shouldn't need the compiler to tell you that you can't. You, the programmer who designed the program in the first place, should know better.

Are there any BASIC dialects that use nested functions? I wouldn't be opposed to Galleon adding that, nor would I be opposed to him not adding it. The presence of a feature doesn't mean that I have to use it.

Calling functions via pointers would be kind of cool. QBASIC allowed calling custom functions by pointer using CALL Absolute, although I wouldn't call that full support of function pointers, as I'm not aware of any direct built in way of getting the offset of a traditional QBASIC function. Anyway, I digress...

Regards,
Michael

P.S. Edited to fix a typo. Nested functions are not part of C89. I had said that they are, but meant to say that they aren't.
« Last Edit: October 08, 2011, 05:14:08 AM by mcalkins »
The QBASIC Forum Community: http://www.network54.com/index/10167 Includes off-topic subforums.
QB64 Off-topic subforum: http://qb64offtopic.freeforums.org/

kidfrommars

  • Full Member
  • ***
  • Posts: 215
    • C & Fortran Polyglot
Re: 'Local' Functions and Subs within Functions and Subs
« Reply #18 on: October 07, 2011, 07:08:20 PM »
@mcalkins: Well said.

DeeBee

  • Sr. Member
  • ****
  • Posts: 491
    • Donnelly-House
    • Email
Re: 'Local' Functions and Subs within Functions and Subs
« Reply #19 on: October 08, 2011, 12:11:08 AM »
Quote from: mcalkins on October 06, 2011, 09:25:31 PM
{snip}

I have programmed in most programming methods (or paradigms, whatever), and am fluent in several languages,
proficient in several others, and have programmed in many others, from machine code and assembly to "older"
languages like COBOL and FORTRAN, to more modern languages like C, Pascal and Java, and OOP.

If you look at that link I provided ( http://en.wikipedia.org/wiki/Comparison_of_programming_paradigms )
you will see in the one table that it actually states under Structured Programming, "A style of Imperative programming
with more logical program structure" and "Indentation, absence of GOTO statements", as a simple and
quick description and differentiation. (that is, a step beyond Imperative Programming, which is what the original
BASIC programming language(s) was / were)

And under Procedural Programming, "Derived from structured programming, based upon the concept of
modular programming or the procedure call" and "Local variables, sequence, selection, iteration, and modularization".

GOSUB is just a "GOTO SUBROUTINE" (and RETURN).

There is no real "modularity" in the use of GOSUB's. (since they are generally "global", with use of global variables,
which, by definition and "best practices", should be avoided)

Therefore, a "procedural programmer" should avoid the use of GOTO and GOSUB, even if the language allows their use.
They are "old style" programming commands and used effectively improperly in "modern programming".
That is why FUNCTION and SUB were added to QB, to make it more "modern", so people could start programming
"procedurally", because that is preferable to "imperatively" and "structured". (there is a programming paradigm history
involved in the evolution of programming methods and languages -- it is not that they are simply "different")

If you want to "flop around" as a programmer, and not try to learn and become a better programmer, and
denounce important programming concepts (that "real programmers" (professionals) use and understand),
like "best practices", and the like, then whatever.

I have, however, always tried to better myself as a programmer (and in other ways), which has made me a
better and stronger, and more successful, programmer, in pretty much every aspect of programming, which,
is more than just "coding", and involves understanding as much as possible about the different aspects,
paradigms, methods, theories, concepts, and languages, of programming, and also something of its history.
« Last Edit: October 08, 2011, 12:33:30 AM by DeeBee »

Clippy

  • Hero Member
  • *****
  • Posts: 16431
  • I LOVE π = 4 * ATN(1)    Use the QB64 WIKI >>>
    • Pete's Qbasic Site
    • Email
Re: 'Local' Functions and Subs within Functions and Subs
« Reply #20 on: October 08, 2011, 08:28:04 AM »
"Proper programming techniques" are in the mind of the RULE MAKER. They not only LIMIT you, but they force you to ABANDON things that CLEARLY WORK in favor of a more RIGID format for NO REAL PURPOSE except to FORCE THEIR WILL on others.

That kind of CRAPTRAP is NOT BASIC and NOT NECESSARY NOR DESIRABLE HERE! Do what you like, but don't PRETEND to FORCE RULES that are COMPLETELY UNNECESSARY on the rest of us!
QB64 WIKI: Main Page
Download Q-Basics Code Demo: Q-Basics.zip
Download QB64 BAT, IconAdder and VBS shortcuts: QB64BAT.zip
Download QB64 DLL files in a ZIP: Program64.zip

DeeBee

  • Sr. Member
  • ****
  • Posts: 491
    • Donnelly-House
    • Email
Re: 'Local' Functions and Subs within Functions and Subs
« Reply #21 on: October 08, 2011, 01:08:04 PM »
Wadr, spoken like someone who obviously doesn't know what they are talking about.

  • Print