Recent

Author Topic: Frankenstein Pascal  (Read 7459 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 2503
Re: Frankenstein Pascal
« Reply #90 on: April 09, 2021, 09:13:50 am »
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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 9269
  • FPC developer.
Re: Frankenstein Pascal
« Reply #91 on: April 09, 2021, 11:22:44 am »
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.

Quote
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

  • Sr. Member
  • ****
  • Posts: 465
Re: Frankenstein Pascal
« Reply #92 on: April 09, 2021, 12:46:31 pm »
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.
« Last Edit: April 09, 2021, 01:18:11 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

Thaddy

  • Hero Member
  • *****
  • Posts: 10784
Re: Frankenstein Pascal
« Reply #93 on: April 09, 2021, 02:02:15 pm »
Well, put those vars in a record and call default() on it.
Problem solved...

AlanTheBeast

  • Full Member
  • ***
  • Posts: 187
  • My software never cras....
Re: Frankenstein Pascal
« Reply #94 on: April 09, 2021, 02:12:54 pm »
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.
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

devEric69

  • Sr. Member
  • ****
  • Posts: 465
Re: Frankenstein Pascal
« Reply #95 on: April 09, 2021, 02:21:48 pm »
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).
« Last Edit: April 09, 2021, 03:11:40 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

devEric69

  • Sr. Member
  • ****
  • Posts: 465
Re: Frankenstein Pascal
« Reply #96 on: April 09, 2021, 03:11:57 pm »
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?
« Last Edit: April 09, 2021, 03:16:43 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

PascalDragon

  • Hero Member
  • *****
  • Posts: 2969
  • Compiler Developer
Re: Frankenstein Pascal
« Reply #97 on: April 09, 2021, 03:23:15 pm »
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:

Quote
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

  • Sr. Member
  • ****
  • Posts: 465
Re: Frankenstein Pascal
« Reply #98 on: April 09, 2021, 03:33:00 pm »
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.
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

AlanTheBeast

  • Full Member
  • ***
  • Posts: 187
  • My software never cras....
Re: Frankenstein Pascal
« Reply #99 on: April 09, 2021, 05:50:01 pm »
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.
Everyone talks about the weather but nobody does anything about it.
..Samuel Clemens.

Fred vS

  • Hero Member
  • *****
  • Posts: 2210
    • StrumPract is the musicians best friend
Re: Frankenstein Pascal
« Reply #100 on: April 09, 2021, 06:00:19 pm »
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).
« Last Edit: April 09, 2021, 06:11:50 pm by Fred vS »
I use Lazarus 2.0.6 32/64 and FPC 3.2.0 32/64 on Debian 10.2 64 bit, Windows 10, Windows 7 32/64, Windows XP 32,  FreeBSD 64 and Mac OS X Snow Leopard 32.
Widgetset: fpGUI, MSEgui, Win32, GTK2, Qt, Carbon.

https://github.com/fredvs
https://gitlab.com/fredvs

devEric69

  • Sr. Member
  • ****
  • Posts: 465
Re: Frankenstein Pascal
« Reply #101 on: April 09, 2021, 06:32:01 pm »
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.
« Last Edit: April 09, 2021, 07:43:19 pm by devEric69 »
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

dtoffe

  • New Member
  • *
  • Posts: 43
Re: Frankenstein Pascal
« Reply #102 on: April 10, 2021, 02:16:28 pm »
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".  :D

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

trev

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1438
  • Former Delphi 1-7, 10.2 user
Lazarus 2.1 r65061 FPC 3.3.1 r49223 macOS 10.14.6 Xcode 11.3.1
Lazarus 2.1 r65070 FPC 3.3.1 r49223 macOS 11.2.3 aarch64 Xcode 12.4
Lazarus 2.1 r61574 FPC 3.3.1 r42318 FreeBSD 12.1 amd64 VMware VM
Lazarus 2.1 r61574 FPC 3.0.4 Ubuntu 20.04 Parallels VM
Lazarus 2.0.10 FPC 3.2.0 Win10 Parallels VM

MarkMLl

  • Hero Member
  • *****
  • Posts: 2503
Re: Frankenstein Pascal
« Reply #104 on: April 12, 2021, 09:52:33 am »
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
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018