About Inline Variable

[Fibonacci]

The people who get the final say on implementing features in FPC are just against it. Not because its hard to implement (its not), not because it breaks anything (it doesnt, especially if its behind mode Delphi or a modeswitch), but simply because they dont like it.

They keep repeating the same excuses - that its unreadable, that it goes against the Pascal standard, that "its always been this way, so why change it now". Their subjective opinion (objectively wrong) ends up being the final word. FPC is missing useful features not due to technical limits, but because a few peoples tastes and ideology block the rest.

The usual FPC veterans keep backing those ideological excuses

@Thaddy "inline vars violate the Pascal paradigm"
@Martin_fr "short time convenient. I.e. for a quick and dirty..."
@Thaddy "it is not Pascal"
@jamie "Do we really want this confusion?"

[gues1]

Ok lets see If I can show an example.

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

1. var
2.  A:Integer;
3. Begin
4.   //.. some code;
5.   If whatever then
6.    Begin
7.     Var A:integer;
8.     //Some code
9.    If whatever then
10.      Begin
11.       Var A:integer;
12.      // some Code;
13.     end;
14.  End;
15. End;
16.  

Do we really want this confusion?
Jamie

This is not legal. You cannot use variable names already used anywhere in the unit. But the proper exampleis this:

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

1. var
2.  A:Integer;
3. Begin
4.   //.. some code;
5.   for var B := 10 to 30 do
6.     // .. same code
7.   // here, outside the loop, B doesn't exist. Ther is not confusion.
8.   // N.B: Delphi have insigth (like LSP) and the errors are show in the IDE during the editing, good thing.
9. End;
10.  

[marcov]

FPC is missing useful features not due to technical limits, but because a few peoples tastes and ideology block the rest.

And "The useful features" bit  is not about tasted and ideology? Come on! It is the most shallow copy-cat feature there is. Syntax makeup that doesn't make anything possible that was not possible before. The whole "pro" argument is pointless drama.

Anyway the story is roughly true. There was contention, and when that discussion was held, it seemed that the component builders mostly refrained from it, a decision was postponed. We were aware of Delphi change to  to a subscription model that forces users to newest version, and that in the long run it will probably be inevitable.

But even then, I don't see any reason to fast track it. It would be aeons till it is in releases anyway, if it were implemented in trunk now.

[gues1]

I propose don't start again another "var inline" discussion.

All of us have understood tha FPC team has choosen to skip that features by now. In the future we are going to see.
But now stop this discussion.

[Martin_fr]

@Thaddy "inline vars violate the Pascal paradigm"
@Martin_fr "short time convenient. I.e. for a quick and dirty..."
@Thaddy "it is not Pascal"
@jamie "Do we really want this confusion?"

None of those are FPC team. None of those are decision makers for that particular issue.

I am Lazarus team => and there making mainly decisions on the Debugger (within the limits given by external factors / e.g. properties are a problem in the compiler) and SynEdit.

But, yes, a few make that decision... The few that do the work.

Then again, non of those few, and non others have made the decision that the project can't be forked by anyone who want to go a different path. Other open source projects went through that.
- So, if someone wants that feature, well no one stops them.
- But if someone wants the feature done by somebody else, then you need to convince that somebody else.

[Fibonacci]

And "The useful features" bit  is not about tasted and ideology? Come on!

Perhaps. But the taste of a few ends up deciding how everyone else (the majority) is allowed to write code.

It would be aeons till it is in releases anyway, if it were implemented in trunk now.

Im under the impression that most active FPC coders just use trunk anyway, so that doesnt really seem like a problem.

None of those are FPC team. None of those are decision makers for that particular issue.

They are the "FPC veterans" who keep backing the usual excuses for not implementing new features.

forked by anyone who want to go a different path

Then it becomes hard to share open source code with the community, since using or contributing to such a project would require a specific forked compiler.

[Fibonacci]

I propose don't start again another "var inline" discussion.

Nah! This is a battle worth fighting!

[Martin_fr]

None of those are FPC team. None of those are decision makers for that particular issue.

They are the "FPC veterans" who keep backing the usual excuses for not implementing new features.

So being around for longer forbids me to voice my opinion? But you can voice yours and repeat arguments that (you or others) made before?

[Fibonacci]

So being around for longer forbids me to voice my opinion?

Nobody said your opinion isnt welcome, but that doesnt mean it cant be questioned or challenged.

[Martin_fr]

So being around for longer forbids me to voice my opinion?

Nobody said your opinion isnt welcome, but that doesnt mean it cant be questioned or challenged.

Sure. But what has that got to do with how long I have been around? Is that age-ism? My opinion isn't good because I was born to long ago? Or just about, the time I have been involved with the project? Kind of alleging that as a long time user I must be too conservative?

What has my person to do with the correctness (or opposite) of my statement?


Don't worry, I don't take it personally. I can weather worse than that. Nor will I hold it against you or anyone, I have made my own questionable statements over time.

But, well right back at you: I can question others opinion too. And I can question how they present that opinion.


As for the part about "a few ... opposing it", that hinting at it would be a minority... Well, in my view, it's a few asking for it. Seems to be the battle of the few against the few

[MarkMLl]

I do not intend to be an active part of yet another of the interminable arguments that this community is devolving into, but:

They are the "FPC veterans" who keep backing the usual excuses for not implementing new features.

As a Pascal veteran, using the language since the early 1980s, I feel entitled to say my bit.

The rule that the index variable should be treated as having no consistent variable on normal termination of a for loop is one of the dumber things Wirth did.

The exception that the index variable can be assumed to have a consistent variable if a for loop is broken out of is one of the dumber things that whoever  introduced  break  into Pascal did.

The lack of an alias in a with, intended to indicate exactly what was being referred to, is similarly dumb: it's analogous to designing a for statement without an explicit index variable.

Using a for or with statement to declare a local variable and assign its initial value is consistent with the Pascal (and ALGOL) rule that all variables should be declared before use, provided that the scope is /precisely/ the following statement (which might, as usual, be a compound statement). Whether or not this implies a new stack frame is an implementation detail.

I fully accept that declaring a variable at an arbitrary position within a sequence of statements is anathema, and I fully accept that implicit declaration of a variable or any attempt to declare a variable without an explicit type "just ain't Pascal". And I don't give a damn if there are people in the Delphi community who think that such things are OK.

MarkMLl

[Fibonacci]

As a Pascal veteran

I don't give a damn if there are people in the Delphi community who think that such things are OK.

Exactly. You just proved my point.

[marcov]

And as there is no progress in this thread, it is now locked.