D Enhancment proposals
Kirk McDonald
kirklin.mcdonald at gmail.com
Mon Mar 19 17:35:44 PDT 2007
Bill Baxter wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>
>> Bill Baxter wrote:
>>
>>> Derek Parnell wrote:
>>>
>>>> On Mon, 19 Mar 2007 15:05:29 -0700, Andrei Alexandrescu (See Website
>>>> For
>>>> Email) wrote:
>>>>
>>>>
>>>> I wish it wasn't so hard to get a simple straight answer from the
>>>> experts.
>>>
>>>
>>> I think discussion would much improved if big changes like this
>>> actually came with a detailed proposal on a website somewhere that
>>> people could refer to and which would actually be updated to reflect
>>> vague points clarified during discussion. As it is, there are a lot
>>> of points that have been clarified, and questions answered, but
>>> they're strewn across 100 different posts. I'm pretty lost. I gave
>>> up trying to follow this myself. I'm hoping you'll figure it out and
>>> post something coherent. :-)
>>>
>>> On the bright side, thanks to Andrei, at least there *is* an open
>>> discussion going on about the feature before it just shows up in the
>>> change log as a done deal.
>>
>>
>> I agree. (How couldn't I? Flattery goes a long way :o).)
>>
>> Maybe we could imitate what other languages do, e.g. Perl has the
>> famous "apocalypses" that describe each language feature in detail.
>
>
> I was thinking more of Python's PEPs, but yeh, same deal. I like PEPs
> in that anyone can submit one, get it assigned an offical number. As
> opposed to Larry's stone tablets brought down from the mountain top for
> the rest of us to ooh and ahh over. Python's way is a little more
> egalitarian.
>
> Semi-official Enhancement Proposals are also a good way to handle the
> many repeated requests for 'feature X'. Just tell 'em -- great idea,
> now go write a DEP for it. If they actually do it, then great. Next
> time someone asks for the feature you just point 'em to the previous DEP
> and the BFD ruling on it.
>
> My impression is that PEPs get weighted somehow based on how fleshed-out
> they are. For instance it seems a majority of PEPs (at least the ones
> I've read) come complete with prototype implementations. So PEP is more
> than just a vague wish like "Please implement Java-style serialization".
> It has to contain the nitty gritty details.
>
> --bb
The PEP numbers are also a convenient way to refer to certain issues or
features: "Oh the 'with' statement? That's PEP 343." The PEP can also
serve as a starting point for the official documentation of the feature.
Most importantly, they serve as a fixed locus of discussion, and can
vastly improve the low signal-to-noise ratio that running around in
circles on a mailing list or newsgroup can cause.
In other words:
DEPs++
--
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
More information about the Digitalmars-d
mailing list