Permalink
ReplyOn Wednesday, 15 June 2022 at 05:55:29 UTC, forkit wrote:
>I'm getting off ;-)
Bye!
Don't hurry to leave, you can fork it! Change the 'd' source code yourself!
then, we have a new 'd' compiler!
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to forkit | ||||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Zoadian | On Tuesday, 14 June 2022 at 22:08:31 UTC, Zoadian wrote: > >Ok, you got me. should it even be possible? does anyone write such code in practice? it looks confusing as hell to me. It would become even more ugly if there are multiple private variables, because in that case you would need to put each of them in its own sub-class with its own set of friends. But the point is: in C++ it IS possible to encapsulate each variable so, that it can be accessed only by an explicitly defined set of functions (the friends of the subclass). This is today not possible in D. We can make it possible (and much less ugly) with two UDAs, one to hide the variables and one to explicitly allow access to specific variables. Unlike @hidden alone this allows us to do things that are currently impossible, so it brings real benefit. | |||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Ola Fosheim Grøstad | On Wednesday, 15 June 2022 at 06:26:51 UTC, Ola Fosheim Grøstad wrote: >On Wednesday, 15 June 2022 at 02:15:16 UTC, norm wrote: >D's only real problem is people power. This is a not true at all. D would end up in the same position no matter how many people you throw at it. You first need to:
This sound good, but not must be this way. In my humble opinion, D lake of good betterC library creator. With current betterC status, it can do so much more than C. There is a few like mir and d-uring. BetterC has problem, but much stable compare to Druntime if you build up your own std base on it. It also generate much more higher performance code compare Druntmime with exception. | |||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to test123 | On Wednesday, 15 June 2022 at 07:04:39 UTC, test123 wrote: >This sound good, but not must be this way. In my humble opinion, D lake of good betterC library creator. With current betterC status, it can do so much more than C. There is a few like mir and d-uring. BetterC has problem, but much stable compare to Druntime if you build up your own std base on it. It also generate much more higher performance code compare Druntmime with exception. Yes, you could also scale down and reduce the scope to "betterC". But as long as adding features is important you have to change the process/architecture. | |||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Ola Fosheim Grøstad | On Wednesday, 15 June 2022 at 06:26:51 UTC, Ola Fosheim Grøstad wrote: > > > So there are two realistic options: > > A. View dmd as legacy and switch focus to SDC or some other clean slate approach, help out by setting clear goals, create a documented architecture, set up an iterative process. > > B. Adopt the informal process for dmd, and modify it by creating a clear separation between people who create and people who do quality assurance. Give the latter team full veto power. Then create a plan for giving dmd an architecture. > > Option A is probably easier and cheaper. or... https://youtu.be/43sjym5ZS68?t=1428 | |||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Dom Disc | On Wednesday, 15 June 2022 at 06:55:35 UTC, Dom Disc wrote: >On Tuesday, 14 June 2022 at 22:08:31 UTC, Zoadian wrote: > >Ok, you got me. should it even be possible? does anyone write such code in practice? it looks confusing as hell to me. It would become even more ugly if there are multiple private variables, because in that case you would need to put each of them in its own sub-class with its own set of friends. But the point is: in C++ it IS possible to encapsulate each variable so, that it can be accessed only by an explicitly defined set of functions (the friends of the subclass). This is today not possible in D. This isn't something you want to do frequently, but it makes sense in the rare case where you deal with deadlock issues or other dangerous things! :-) While module-based encapsulation is ok for modest complexity situations, it is sometimes useful to make everything object-private and then open up when you need it. I recently ported some big javascript thing to TypeScript and it was very useful to first convert to classes, then make all fields private first, then remove the privacy until the compilation was successful. That gave me a better understanding of what the structure was. | |||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grøstad | On Wednesday, 15 June 2022 at 06:26:51 UTC, Ola Fosheim Grøstad wrote:
>
> So there are two realistic options:
>
> A. View dmd as legacy and switch focus to SDC or some other clean slate approach, help out by setting clear goals, create a documented architecture, set up an iterative process.
>
> B. Adopt the informal process for dmd, and modify it by creating a clear separation between people who create and people who do quality assurance. Give the latter team full veto power. Then create a plan for giving dmd an architecture.
>
> Option A is probably easier and cheaper.
btw. what is this SDC thing?
Is it a D compiler?
Does it inherit all the problems of the current compiler, or is it 'more modular', like the approach LLVM have taken, so that more people can work on it?
I'm doubt that another monolithic compiler, will solve very much at all. They just quickly reach a point where they're too complex, and nobody dares touch it.
| |||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
Posted in reply to forkit | On Wednesday, 15 June 2022 at 07:40:37 UTC, forkit wrote: >btw. what is this SDC thing? Is it a D compiler? That seems to be the long term goal: https://github.com/snazzy-d/SDC >Does it inherit all the problems of the current compiler, or is it 'more modular', like the approach LLVM have taken, so that more people can work on it? I believe it is done 100% from scratch, so I would expect it to be layered and modular, but I am not involved with it. I would expect the architecture to evolve at such an early stage, so I assume that those who engage with it can improve on the architectural design, but I assume you would have to ask the people who are actively pursuing it to get real answers. | |||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to forkit | On Wednesday, 15 June 2022 at 07:40:37 UTC, forkit wrote: >On Wednesday, 15 June 2022 at 06:26:51 UTC, Ola Fosheim Grøstad wrote: >[...] btw. what is this SDC thing? Is it a D compiler? Does it inherit all the problems of the current compiler, or is it 'more modular', like the approach LLVM have taken, so that more people can work on it? I'm doubt that another monolithic compiler, will solve very much at all. They just quickly reach a point where they're too complex, and nobody dares touch it. It's a completely new frontend for D It aims to solve the tooling issues for D development, while also being a full fledged compiler in it's own right | |||
June 15, 2022 Re: Adding a new design constraint to D | ||||
|---|---|---|---|---|
| ||||
 Posted in reply to Dom Disc | On Tuesday, 14 June 2022 at 20:22:17 UTC, Dom Disc wrote:
> class C
> {
> private int _hidden_x;
> private int _hidden_y;
> @limitPrivateAccess(_hidden_x) foo(x)
> {
> _hidden_x = x;
> _hidden_y = 0; // error: foo has no access to _hidden_y
> }
> }
>
> So foo would normally have access to _hidden_y although the developer doesn't want that. That is so because today _all_ member functions (and friends) have access to _all_ private variables. The new UDA @limitPrivateAccess restrict this to only those private variables given as its parameters.
> Together with a new privacy-level "@hidden" we could even have variables that no-one has access to, except those functions that are explicitly allowed to access them via the UDA. This would be the ultimate restriction level.
my mind is boggling LOL
seriously though, the access restrictions must be declared by the provider, to limit the notional consumer. Here the provider is restricting itself, it's pointless.
| |||
Copyright © 1999-2021 by the D Language Foundation