Frankenstein Pascal

[MarkMLl]

Unfortunately the end result is that it broke a lot of code (including in Lazarus).

And the developers dropped it on everybody with no use of the "experimental" etc. procedure attributes which would at least have resulted in a compilation warning.

It was amateur in the extreme, and seriously dented my confidence in both the language and developers.

MarkMLl

[marcov]

Unfortunately the end result is that it broke a lot of code (including in Lazarus).

And the developers dropped it on everybody with no use of the "experimental" etc. procedure attributes which would at least have resulted in a compilation warning.

That's what user changes release manifests are for. If you only read one FPC documentation page every five years, read the user changes for major compiler versions.

It was amateur in the extreme, and seriously dented my confidence in both the language and developers.

It was an undocumented side effect. Note that the argument against the side effect was exactly the mirror of what is posted in this thread. Now it is fixated and documented. EOD

[devEric69]

Code: Pascal  [Select][+][-]

1. var
2.   iVariable1, iVariable2, iVariable3: integer = 0;
3.  

Hello with my 2 cents: I would like too, to see this implemented. This would allow us to compete with VB3..VB6 :O) . It could be useful for a "in mass" and quick initialisation of variables, with only one line, in an RTTI way.

[Thaddy]

Well, put those vars in a record and call default() on it.
Problem solved...

[AlanTheBeast]

Well, put those vars in a record and call default() on it.
Problem solved...

That's a problem created.  The proposed change is a natural IMO.

Once upon a time Pascal did not have initialization of a variable in the declaration.  Now it does.

That that doesn't clear or initialize an array is incomplete.

[devEric69]

I think like @AlanTheBeast (normal, as he's the best).

I know the default statement: but, it's less "natural" and practical, than a direct assignment with a real value (0, or 55, or nil for a pointer) at the moment of declaration. And such a solution would less pollute the visual of the debugger on such traced variables.

It could also be useful in order to distinguish a locally initialized variable (what I call a "local static" variable, i.e. reified from call to call of a same routine), to quickly distinguish its original assignment value from another assignment further down in the same event (e.g. eliminating the problem of reentrance in the same event due to the side effects of the same said event).

[devEric69]

Well, after re-reading of myself, the problem seems to be solved with the const keyword (nevertheless, it's strange; I would have done that in vars). Isn't it?

[PascalDragon]

And as far as breaking changes go the cavalier way that the developers broke FileExists() in 3.2.0 severely dented my confidence. If there were a better hole I'd go to it.

With the extension for the support to follow symbolic links or not (which was due to Delphi compatibility) it was decided to make the behaviour consistent across platforms.

Unfortunately the end result is that it broke a lot of code (including in Lazarus). And as for consistency, how do you rename a directory? Of course, you use renameFile() ! How's that for consistency? Especially when the justification provided was:

FileExists on Unix-based systems
Reason for change: Directories are not files, thus it was illogical for FileExists to return True for existing directories. Also this brings it in line with Windows and Delphi.

Directories are not files on UNIX /UNIX-like systems? Really? But they are when they need renaming? Talk about consistency.

Complain to Borland about this "inconsistency". Or heck, even Microsoft, cause that's what the Delphi API in this case is based on as they have MoveFile to rename both directories and files.

And it simply was a bad idea back then to have that difference in FileExists and to have it documented.

[devEric69]

Well, after re-reading of myself, the problem seems to be solved with the const keyword (nevertheless, it's strange; I would have done that in vars). Isn't it?

Hello @all,

I wanted to add, that old VB knew how to do that, in the vars. I'm sure of that. And AFAIK, a constant is indeed a constant.

[AlanTheBeast]

I think like @AlanTheBeast (normal, as he's the best).

3rd or 4th, but I am the humblest.

to quickly distinguish its original assignment value from another assignment further down in the same event (e.g. eliminating the problem of reentrance in the same event due to the side effects of the same said event).

In a procedure or function, each instance would have its own stack vars therefore its own 'clean' start ... earlier instances would retain what they have.

[Fred vS]

Well, after re-reading of myself, the problem seems to be solved with the const keyword (nevertheless, it's strange; I would have done that in vars). Isn't it?

Hello @all,

I wanted to add, that old VB knew how to do that, in the vars. I'm sure of that.

Hum, if Delphi does not do it, better forget it.
Or maybe wait until the proposal reaches adulthood (the suggestion is very young, it is only 7 years old).

[devEric69]

I think like @AlanTheBeast (normal, as he's the best).

3rd or 4th, but I am the humblest.

Oh! I understand @AlanTheBeast. I hope you're not being too hard with yourself.

Hum, if Delphi does not do it, better forget it.

Delphi, I don't believe (or I've never noticed it). But at least for old VB5, it's sure from memory (1997), even if it's off-topic with fcp.

[dtoffe]

In the german language there is a Proverb for something like that: "Verschlimmbessern" (I have no idea how to translate that into english

The Internet English translation of that word is "improveworsement". 

I got "disimprovement" or "disimprove", funny...

[trev]

Feature bloat: Psychology boffins find people tend to add elements to solve a problem rather than take things away

[MarkMLl]

Feature bloat: Psychology boffins find people tend to add elements to solve a problem rather than take things away

Agreed. But this is related to toughening up the underlying language, and over the years the increase in program size and the increased number of ways that a program can be exposed to malefactors means that anything that increases the likelihood that variables be properly initialised and tightens up scoping rules confers a reliability advantage.

The alternative to ensuring that programmers correctly initialise variables and understand their scope is to limit the size of their programs, and to ban public systems (web servers etc.).

MarkMLl