D Enhancment proposals

[Kirk McDonald]

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