http://dlang.org/library/std/digest/digest/digest.html

Ugh. -- Andrei

On 1/7/15 2:09 AM, Andrei Alexandrescu wrote:
> http://dlang.org/library/std/digest/digest/digest.html
>
> Ugh. -- Andrei

I remember this from the movie "being std.digest" when digest goes through the tunnel and becomes himself.

-Steve

On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei Alexandrescu wrote:
> http://dlang.org/library/std/digest/digest/digest.html
>
> Ugh. -- Andrei

This thread needs more digest:

http://dlang.org/library/std/digest/digest/digest.digest.html

On 1/8/15 4:46 AM, aldanor wrote:
> On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei Alexandrescu wrote:
>> http://dlang.org/library/std/digest/digest/digest.html
>>
>> Ugh. -- Andrei
>
> This thread needs more digest:
>
> http://dlang.org/library/std/digest/digest/digest.digest.html

Heh. Alright, any lieutenant who could get on this?

There's a sense of urgency - these pages are live now.


Andrei

Am Thu, 08 Jan 2015 07:44:17 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 1/8/15 4:46 AM, aldanor wrote:
> > On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei Alexandrescu wrote:
> >> http://dlang.org/library/std/digest/digest/digest.html
> >>
> >> Ugh. -- Andrei
> >
> > This thread needs more digest:
> >
> > http://dlang.org/library/std/digest/digest/digest.digest.html
> 
> Heh. Alright, any lieutenant who could get on this?
> 
> There's a sense of urgency - these pages are live now.
> 
> 
> Andrei
> 

What kind of action would you expect? Renaming a name
which has been used for two years now without complaints, simply
because it looks bad in the new documentation?

As we usually don't rename functions with inconsistent naming or otherwise bad names because of  backwards compatibility (TM) I guess that's not what you want. OTOH I'm not sure if ddox could be much improved in this regard. Maybe it shouldn't display the full name, only Class.member. But I don't really know what you expect.

On 1/8/15 8:19 AM, Johannes Pfau wrote:
> What kind of action would you expect? Renaming a name
> which has been used for two years now without complaints, simply
> because it looks bad in the new documentation?
>
> As we usually don't rename functions with inconsistent naming or
> otherwise bad names because of  backwards compatibility (TM) I guess
> that's not what you want. OTOH I'm not sure if ddox could be much
> improved in this regard. Maybe it shouldn't display the full name,
> only Class.member. But I don't really know what you expect.

I was thinking along the way of simplifying documentation and links. -- Andrei

Am Thu, 08 Jan 2015 08:27:50 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 1/8/15 8:19 AM, Johannes Pfau wrote:
> > What kind of action would you expect? Renaming a name
> > which has been used for two years now without complaints, simply
> > because it looks bad in the new documentation?
> >
> > As we usually don't rename functions with inconsistent naming or otherwise bad names because of  backwards compatibility (TM) I guess that's not what you want. OTOH I'm not sure if ddox could be much improved in this regard. Maybe it shouldn't display the full name, only Class.member. But I don't really know what you expect.
> 
> I was thinking along the way of simplifying documentation and links. -- Andrei

I guess that should be done by somebody familiar with the ddox codebase
then. Two small improvements that could help:
* Make names/filenames case sensitive
* display only shortened names (Class.member, Module.member)

This leaves the URL/link problem but I don't know how that could be solved.

On Thursday, 8 January 2015 at 16:27:48 UTC, Andrei Alexandrescu wrote:
> On 1/8/15 8:19 AM, Johannes Pfau wrote:
>> What kind of action would you expect? Renaming a name
>> which has been used for two years now without complaints, simply
>> because it looks bad in the new documentation?
>>
>> As we usually don't rename functions with inconsistent naming or
>> otherwise bad names because of  backwards compatibility (TM) I guess
>> that's not what you want. OTOH I'm not sure if ddox could be much
>> improved in this regard. Maybe it shouldn't display the full name,
>> only Class.member. But I don't really know what you expect.
>
> I was thinking along the way of simplifying documentation and links. -- Andrei

This is a problem with naming, not with DDox. It would look bad regardless of generator, or regardless of documentation at all. You could make it look slightly less bad, but you might end up hurting other documentation. (I'm not implying  it should be renamed (bad reason for breaking compatibility), but I see no point in changing doc generation just because of some bad naming.)

On 1/8/15 9:16 AM, Kiith-Sa wrote:
>
> This is a problem with naming, not with DDox. It would look bad
> regardless of generator, or regardless of documentation at all. You
> could make it look slightly less bad, but you might end up hurting other
> documentation. (I'm not implying  it should be renamed (bad reason for
> breaking compatibility), but I see no point in changing doc generation
> just because of some bad naming.)

Sigh. No matter how I look at it, the same name repeated FOUR times only evokes Java's factory factory etc. -- Andrei

On Thu, Jan 08, 2015 at 10:50:10AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 1/8/15 9:16 AM, Kiith-Sa wrote:
> >
> >This is a problem with naming, not with DDox. It would look bad regardless of generator, or regardless of documentation at all. You could make it look slightly less bad, but you might end up hurting other documentation. (I'm not implying  it should be renamed (bad reason for breaking compatibility), but I see no point in changing doc generation just because of some bad naming.)
> 
> Sigh. No matter how I look at it, the same name repeated FOUR times only evokes Java's factory factory etc. -- Andrei

Yes, good ole Java verbosity with class Chocolate, class ChocolateFactory, class ChocolateFactoryFactory, class ChocolateWrapper, class ChocolateWrapperFactory, class ChocolateWrapperFactoryFactoryWrapper, ad nauseaum. Utterly delicious.

</sarcasm> :-P


T

-- 
It won't be covered in the book. The source code has to be useful for something, after all. -- Larry Wall