On Wed, Feb 20, 2019 at 10:25 AM Henry Vermaak <[email protected]> wrote: > > On Wed, Feb 20, 2019 at 09:47:20AM -0300, Marcos Douglas B. Santos > wrote: > > On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak > > <[email protected]> wrote: > > > I'm mostly more interested in limiting the scope to prevent > > > accidental use, like you. It can also offer more fine grained > > > control of where managed variables get freed. > > > > Try to see restrictions as a good thing. In this case, which Pascal > > doesn't allow to declare inline variables, you must split big > > functions, which has many local variables, in others to have a better > > understanding of the algorithm. At the end, you might have a better > > design and reuse of the code. Everybody wins: you, your code, Pascal > > team - as they don't need to change the compiler - and Niklaus Wirth > > might not throw a curse in us. > > I don't have many big functions and I've missed scoped variables in > Pascal since the early 1990s. It's been standard good practice in > software engineering for decades and all the languages I work with > support it because it's a good idea, not because it's some newfangled > fad. > > But big functions happen in the real world. The fpc compiler source has > dozens of extremely long functions. Lazarus too. I think the windproc > function in the win32 interface is more than 700 lines (look at > TWindowProcHelper.DoWindowProc).
Yes, you're right. Big functions happen in the real world... But it doesn't mean those functions are well written only because they exists. IMHO, instead of support those functions, let use a better design to create them. regards, Marcos Douglas _______________________________________________ fpc-devel maillist - [email protected] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
