Because the problem is not big enough? The one or two that occasionally happen in a header are easier fixed by hand?
That's an interesting comment. If the problem is so small and trivial then how come FPC is missing so many APIs and structure definitions ? ...
You don't solve "small" problems ?
(Automated conversion is overrated in practice anyway,
Of course, a programmer's dream come true is to translate thousands of APIs and data structure definitions by hand. It is very kind of you not to want to deprive programmers of such pleasures.
Trying to find the next best remote detail to justify a solution to what is a non-problem?
It's a non-problem for people who don't program. There is no doubt in my mind that API function and data structure definitions are likely a non-problem to the average shoe salesman but, for most programmers, they tend to make themselves needed.
Seen from that viewpoint, you're right, it really is a non-problem for a significant percentage of the population.
The 1:1 relation simply doesn't exist. For one thing, declarations are sorted.
There is a 1:1 relation in the translation of API headers. There is _no good_ reason why there isn't a 1:1 relation when translating data structures.
Not really. If you want to check that you need unittests rather than source inspection anyway. See e.g. Wine.
Yes, really. Parallelism does go out the window when there isn't a 1:1 between the original and the translation. Wine is neither here nor there in the subject.
....For the duration of translating one union out of a mega headerset.
one union ?... are you inspecting a bacon-cheeseburger API ? ... because Windows certainly has quite a few more data structure definitions that include a union and even multiple of them in the struct definition and, many of them are tedious to translate "manually" because Pascal is somewhat lacking in that area.
As said, syntax microoptimization for a non-problem.
This has nothing to do with "microoptimization" but... if I have to see how it has something to do with it, do feel free to enlighten me (I suspect you will anyway... though I refer to it as enlightenment because of my generous nature)
More syntax is worse than the problem it solves.
Nice technique. You declare something and, because you did, it must be true. Move over Bertrand Russell.
Your reasoning is that people would select a model T over a new car simply because it had a shade of colour that is not available for the new car. Totally disregard for proportion.
Nice try. My "reasoning" is that if you were in charge of car designs, we'd all be driving Model Ts with triangular wheels (microoptimizing the wheels making them round would not solve any problem since the car can move with the wheels it has)
And of course the elephant in the room is that users select languages more for framework than language details to begin with.
Users hopefully (but not always, unfortunately) select the tool that makes the task easiest to accomplish correctly. For some users, myself among them, it's rather "convenient" to have a complete set of API function and structure definitions (one of the very few things I miss about C/C++). Having to deal with an incomplete set of APIs and, an often enough, not straightforward conversion of data structures, takes some shine away from the tool.
"What can I achieve in a short time with it?" is the central user tenet, and that is governed MORE by libraries than by language details.
If all a programmer cares is how long it takes to achieve something with the language, they can spend their day writing "hello world" programs. Even a beginning programmer should be able to write a few of them every day.
You should give some thought that some programmers use a programming language for what they can accomplish with it and, if the language doesn't have the necessary capabilities to implement the target task then the time spent with that tool will be _zero_.
Which is why the "change this language feature and more users will come" argument is fundamentally flawed.
Did anyone say something to the contrary ?... I must have missed it.
Micro language optimization only matters for language discussions in forums.
You're rather fond of that meaningless term "micro language optimization". You get to pepper your deficient arguments with it to make them sound impressive. Good stuff but, I have seen that syntax before.
Marco,
I got to give you credit for being very consistent. Any discussion of anything that could potentially help FPC go forward is "micro optimization" you don't want to have anything to do with. That syntax horse is so dead by now... what a beating it got... poor thing.