Discusssion on the Discussion of the Design for a new GC
Joakim via Digitalmars-d
digitalmars-d at puremagic.com
Wed Apr 23 09:40:25 PDT 2014
On Wednesday, 23 April 2014 at 15:33:36 UTC, Orvid King wrote:
> So, in order to get the ball rolling on the new GC I intend to
> implement for D, I want to facilitate a lively discussion of
> the design of it, so that it can be designed to be both robust
> and free of design flaws. To keep the discussion from getting
> derailed, I want to lay out a few guidelines, but want to get
> feedback on those guidelines before I actually implement them.
> My current draft of them is as follows:
>
> First we’ll start with a brief overview of the development
> process:
> A PR will be created for DMD, DRuntime, and, although it may
> stay empty, Phobos. A new commit will be created for each
> update of the implementation, this includes bug fixes, and
> continuing work on the implementation, in as many iterations as
> are required. This is done to allow progressive review of the
> code rather than trying to review the PRs as a whole, because,
> as it is likely to include several thousand lines of changes to
> the code, it would be impractical to review all at once.
> No force push should ever be done to the PRs except to fix a
> typo in or clarify a detail of the commit message for the
> newest commit. If there is a typo in a commit message, or it is
> not very clear on what was actually done, and another commit
> has already been pushed, the typo or un-clear message shall
> remain for all eternity. The suggested remedy in this case is
> to make a note of the typo or clarify the commit message with a
> comment on the commit.
> PRs to the PRs are welcome, it is however encouraged to
> coordinate any work you do with the others actively working on
> the GC. The primary outlet for this should be the IRC, however,
> should the need arise, the mailing list is a valid venue for
> this.
> Github should be used as the primary outlet for discussion of
> actual code, due to the ease of referencing code, as well as
> the ability to tell if a comment is about a piece of code that
> was already changed.
> The mailing list should be used exclusively for discussion of
> the design. It should not be used for discussing snippets of
> code in the actual implementation. It can, and should be, used
> to discuss snippets of code that may demonstrate a flaw,
> weakness, or strength in the design.
> The IRC should be used for rapid-fire Q&A, or bringing someone
> up-to-date with the discussion and progression of the GC so
> far. Discussion about inconsistencies in the coding style of
> the implementation (whitespaces, newlines, etc.) should reside
> exclusively on the IRC, as they are things that a future reader
> of the discussions doesn’t really care about. If a discussion
> of the overall code style used in the implementation is
> required, a thread should be created on the mailing list.
> The IRC should not be used to facilitate a design discussion.
> The reason for this is twofold, firstly the IRC has a limited
> audience, thus limited feedback, and secondly, I want the
> discussion of the design to stand as documentation for why the
> GC is designed the way it is.
>
> Now, on to the guidelines for the design discussion.
> ARC does not exist. We are implementing a GC, however, if the
> opportunity arises to allow an efficient implementation of
> interfacing with an external ARC platform, such as what is used
> in Objective C, discussion of that interfacing mechanism is
> permitted.
> If DMD support is needed, it exists. This means that if the GC
> needs DMD to be capable of something such as scope analysis in
> order to make a particular optimization, then DMD should be
> assumed to be capable of doing that.
> While language additions may be proposed, the design must still
> be able to function should the additions not be done, as the
> additions should only be to allow for additional optimization
> opportunities. For instance, re-introducing scoped class locals.
>
>
>
> After all of that, I intend to include a base draft of the
> design of the GC, along with opening the PRs and committing the
> starting API. So, is there something I’m missing? Am I
> overlooking the obvious? Is there a more practical way to
> produce the same results?
Wow, this takes the D forums tradition of "all talk, no code," or
as the original saying goes, "all hat, no cattle," to a new peak.
;)
I think most would agree with you on most of these guidelines,
better to get onto the actual design. It might help if you put
forth a tentative proposal, that the D goons can then proceed to
destroy... I mean, critically evaluate.
More information about the Digitalmars-d
mailing list