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

[Dimitrios Chr. Ioannidis]

Hi,

Στις 20/2/2019 3:25 μ.μ., ο Henry Vermaak έγραψε:
> 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).

Well, people used to ( apparently still do ) write functions that were 
hundreds, even thousands of lines long and they used to write them in 
plain text editors (think Notepad) without the kind of support Lazarus 
provided. In that environment, declaring a variable hundreds of lines 
away from where it was used meant that the person reading

if (flag) limit += factor;

didn't have a lot of clues about what flag, limit and factor were. 
Naming conventions like Hungarian notation were adopted to help with 
this, and so were rules like declaring things close to where they are 
used. Of course, these days, it's all about refactoring, and functions 
are generally less than a page long, making it hard to get very much 
distance between where things are declared and where they are used. 
You're operating in a range of 0-20 and quibbling that maybe 7 is ok in 
this particular instance, while the guy(s) who made the rule would have 
LOVED to get 7 lines away and was trying to talk someone down from 700. 
And on top of that, in Lazarus, you can mouse over anything and see its 
type, is it a member variable, and so on. That means the need to see the 
line declaring it is lessened.

( not mine but I agree 100% ).


-- 

Dimitrios Chr. Ioannidis