| |
 | Posted by Jonathan M Davis
in reply to Basile B. |  Permalink Reply |
|
Jonathan M Davis 
Posted in reply to Basile B.
| On Monday, August 21, 2023 12:46:47 PM MDT Basile B. via Digitalmars-d wrote:
> On Monday, 21 August 2023 at 18:01:20 UTC, Walter Bright wrote:
> > On 8/21/2023 9:26 AM, Basile B. wrote:
> >> On Monday, 21 August 2023 at 16:19:25 UTC, Walter Bright wrote:
> >>> On 8/21/2023 8:39 AM, Basile B. wrote:
> >>>> Like you pretend that `enum DEFAULTS` is not a workaround the limitations.
> >>>
> >>> I would not use the DEFAULTS, but would spell it out for each system. Then it looks like a table, with rows and columns, and makes it easy to see which setting is for which system.
> >>
> >> you have to read top down to see what DEFAULTS do.
> >
> > That's why I wouldn't use the DEFAULTS approach. Just make a table.
>
> However that approach was used. It really looks like an alternative to a version OrOr. There are plenty of other examples in drutime sources.
>
> Sure at some point there is also the problem of the unix standards...Every distribution can choose its own value for the flag of this func or that one...which creates complexity in C `define`s, but should not in D. There is a problem that is not solved.
The way that version statements try to enforce a lack of boolean logic reflects the way that Walter believes (rightly or wrongly) that versioning code should work based on his experience, but it does not actually prevent you from writing code that uses boolean logic for versioning. It just makes it harder, and given how much most programmers hate code duplication (whereas the way that Walter wants versioning done typically introduces quite a lot of code duplication, even if it's for a good cause), plenty of D programmers routinely work around how version works in order to introduce boolean logic into how they version code. D runtime is not immune to this any more than any other D code, particularly since Walter wrote very little of it. If anything, it probably follows what Walter wants more than most D code, because it's official D stuff, but the way that Walter wants versioning done (while arguably a good idea) strongly goes against how programmers typically function, so it's pretty natural that stuff like this would creep into druntime.
Arguably, stuff like this should be removed from druntime to reflect how Walter wants versioning to be done, but clearly, no one who has spent much time working on druntime has felt strongly enough about it to spend the time to fix the problem, and whoever reviewed the code in question when it was first introduced didn't insist on it being fixed.
Utimately, the fact that people routinely try to work around how version statements work in D doesn't really say anything about whether the reasons for them working the way that they do are good or not. It just shows that (for better or worse) most programmers haven't been brought around to Walter's way of thinking with regards to versioning. In reality, I expect that most of the programmers versioning code in D aren't even aware of why it works the way that it works. They just want to version code the way that comes naturally to them, so they end up fighting how version works rather than adjusting how they function to match.
Personally, I think that Walter is probably right about how versioning should be done, but at the same time, I find it irritating, because it introduces so much code duplication. The code duplication is there to reduce the complexity and reduce the risk of other kinds of problems that typically come with having different versions of the same code, so it is arguably a good a tradeoff, but it often just feels wrong even if it isn't.
That being said, fortunately, most D code doesn't have to worry about version statements much, because druntime hides most of that mess. There are other libraries that wrap C code and/or are more low-level in nature which have to do a fair bit of versioning with code, but most D code is able to be version-agnostic, which fortunately keeps the issues with how how version statements work to a minimum.
- Jonathan M Davis
|
