[fpc-devel] "Blank slate" next version of FPC

Marcos Douglas B. Santos md at delfire.net
Wed Feb 20 15:27:52 CET 2019


On Wed, Feb 20, 2019 at 10:25 AM Henry Vermaak <henry.vermaak at gmail.com> 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
> > <henry.vermaak at gmail.com> 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



More information about the fpc-devel mailing list