Recent

Author Topic: Question ?!!!!  (Read 23274 times)

ydd

  • Jr. Member
  • **
  • Posts: 78
Re: Question ?!!!!
« Reply #75 on: May 15, 2023, 12:07:06 am »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11387
  • FPC developer.
Re: Question ?!!!!
« Reply #76 on: May 15, 2023, 12:28:38 am »
5 Reasons to Use Inline Variables in Delphi
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/

1. opinion, not fact. Clear weasel clause "for many people" to make opinion seem fact.   Worse, it seems to be deliberately one-sided, not mentioning the contra argument that in complex code the downside is having to search the definition inside many code lines instead of a clear position (the VAR block). Though at least that can be mitigated with an IDE (jump to declaration) like functionality. But that goes for both cases.
2. opinion, not fact. and again the weasel words "many people". FPC can turn warnings into errors.
3. Not always less typing. E.g. a few loop vars will have multiple extra VAR's, while in the var block the "VAR" is shared.  But this is still mostly stands.
4. Funny, back then they had exactly the opposite reasoning (mass initializing/finalizing at the start/end is cheaper than multiple times one, options to zero multiple local variables with one rep stosb etc).  Also, in cases where the compiler can determine if a block is taken or not it can chose the  most optimal way, so even if it was a netto plus (which I doubt), this only goes for the most a naive implementation.
5. This is the only one that rings somewhat true from my own experience.
(6, not in article) playing into familiarity feelings from other languages in a "100000 lemmings can't be wrong" sentiment.

So 1 and 4 are simply extreme one sided spotlight on this feature just to make a seem worthy.  The option 2 is extreme corner case and mixes in an opinion about warnings and weaselling "many people" again. All three seem to be carefully crafted to not try to find the other side of the story.

5 is true, and not purely hypothetical. Of course a simple IDE macro would solve it (even easier in lazarus that only has tp append {%H-} or {%w-}. 

The true reason to add it is probably language-feature-by-mob-rule fuelled by perceived benefits (3 and 6).  But not with language design as the article seem to imply.
« Last Edit: May 15, 2023, 12:34:33 am by marcov »

jamie

  • Hero Member
  • *****
  • Posts: 6091
Re: Question ?!!!!
« Reply #77 on: May 15, 2023, 10:50:33 pm »
Inline VAR's only good for the FOR LOOP control where the variable is to be secluded to the loop only and there for will not be present to code outside of that loop.

 As for the use of it anywhere else, NO, Inline variables are not a good idea.
The only true wisdom is knowing you know nothing

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Question ?!!!!
« Reply #78 on: May 16, 2023, 08:31:21 am »
Inline VAR's only good for the FOR LOOP control where the variable is to be secluded to the loop only and there for will not be present to code outside of that loop.

 As for the use of it anywhere else, NO, Inline variables are not a good idea.

I think this is another valid case:

Quote
Py_BEGIN_ALLOW_THREADS

    This macro expands to { PyThreadState *_save; _save = PyEval_SaveThread();. Note that it contains an opening brace; it must be matched with a following Py_END_ALLOW_THREADS macro. See above for further discussion of this macro. It is a no-op when thread support is disabled at compile time.

Py_END_ALLOW_THREADS

    This macro expands to PyEval_RestoreThread(_save); }. Note that it contains a closing brace; it must be matched with an earlier Py_BEGIN_ALLOW_THREADS macro. See above for further discussion of this macro. It is a no-op when thread support is disabled at compile time.

However, both of these cases have declaration of a variable closely associated with entering a block, and the scope of the variable is (or at least should be) restricted to the code inside that block.

I would go so far as to say that having a locally-declared variable is superior for a FOR loop and is closer to Wirth's original intent, since it avoids the pernicious case where the variable is always (in Pascal as originally designed) undefined on exit from the loop.

Hence we either have the Pascal-style

Code: Pascal  [Select][+][-]
  1. var i: integer;
  2. for i := 1 to n begin
  3. ...
  4.  

potentially shortened to something like

Code: Pascal  [Select][+][-]
  1. for i: integer= 1 to n begin
  2. ...
  3.  

or the ALGOL/C/Python style

Code: C  [Select][+][-]
  1. {
  2.   PyThreadState *_save;
  3. ...
  4.  

They are both valid cases, with the minor syntactic variation of whether the declaration is immediately before or immediately after the start of the block.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

alpine

  • Hero Member
  • *****
  • Posts: 1040
Re: Question ?!!!!
« Reply #79 on: May 16, 2023, 09:50:24 am »
5 Reasons to Use Inline Variables in Delphi
https://landgraf.dev/en/5-reasons-to-use-inline-variables-in-delphi/

To me, inline variables cater to programmers laziness. All other "benefits" can be achieved by a feature present into Pascal from the day one (except the 5-th):
Code: Pascal  [Select][+][-]
  1. procedure Outer;
  2.   procedure Inner;
  3.   var I: Integer;
  4.   begin
  5.     for I := 0 to N do
  6.       ...
  7.   end;
  8. begin
  9.   Inner;
  10. end;
i.e. the nested subroutines.

They have their scope, promote organization, care for variables creation/destruction and so on.
"I'm sorry Dave, I'm afraid I can't do that."
—HAL 9000

ASerge

  • Hero Member
  • *****
  • Posts: 2223
Re: Question ?!!!!
« Reply #80 on: May 16, 2023, 04:23:53 pm »
To me, inline variables cater to programmers laziness. All other "benefits" can be achieved by a feature present into Pascal from the day one (except the 5-th):
i.e. the nested subroutines.
They have their scope, promote organization, care for variables creation/destruction and so on.
+1.
A block of code is also automatically documented.
And if someone cares about speed, then you can mark the whole procedure as inline.

 

TinyPortal © 2005-2018