Re: 4x4

2015-01-10 Thread Iain Buclaw via Digitalmars-d
On 8 January 2015 at 21:16, Andrei Alexandrescu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
 On 1/8/15 11:48 AM, Johannes Pfau wrote:

 Am Thu, 08 Jan 2015 10:50:10 -0800
 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:

 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


 These 4x digest variants never occur in real code though:

 http://dlang.org/library/std/digest/digest/digest.digest.html is a
 class member function. You never use the full name,
 it's always instance.digest()

 http://dlang.org/library/std/digest/digest/digest.html could be used
 with the full name. But ironically the name is not used outside of
 std.digest so it's usually not necessary to use the full name.

 So it doesn't look nice in the docs but it's not a huge problem when
 writing code.


 This is a matter common with words that are both noun and verb. Let's have
 a Digest object that digests stuff. I think the review should have prompted
 a name change. -- Andrei




Something that I noticed, having blue as the class=prettyprint
lang-d colour was not a good idea for all things (see the copyright
information at the bottom).

http://dlang.org/library/std/math/tan.html


Re: 4x4

2015-01-08 Thread Steven Schveighoffer via Digitalmars-d

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


Re: 4x4

2015-01-08 Thread aldanor via Digitalmars-d
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


Re: 4x4

2015-01-08 Thread Andrei Alexandrescu via Digitalmars-d

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



Re: 4x4

2015-01-08 Thread Johannes Pfau via Digitalmars-d
Am Thu, 08 Jan 2015 08:27:50 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@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.


Re: 4x4

2015-01-08 Thread Kiith-Sa via Digitalmars-d
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.)


Re: 4x4

2015-01-08 Thread Andrei Alexandrescu via Digitalmars-d

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


Re: 4x4

2015-01-08 Thread Johannes Pfau via Digitalmars-d
Am Thu, 08 Jan 2015 07:44:17 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@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.


Re: 4x4

2015-01-08 Thread Andrei Alexandrescu via Digitalmars-d

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


Re: 4x4

2015-01-08 Thread H. S. Teoh via Digitalmars-d
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


Re: 4x4

2015-01-08 Thread Johannes Pfau via Digitalmars-d
Am Thu, 08 Jan 2015 10:50:10 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:

 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

These 4x digest variants never occur in real code though:

http://dlang.org/library/std/digest/digest/digest.digest.html is a
class member function. You never use the full name,
it's always instance.digest()

http://dlang.org/library/std/digest/digest/digest.html could be used
with the full name. But ironically the name is not used outside of
std.digest so it's usually not necessary to use the full name.

So it doesn't look nice in the docs but it's not a huge problem when
writing code.


Re: 4x4

2015-01-08 Thread Andrei Alexandrescu via Digitalmars-d

On 1/8/15 11:48 AM, Johannes Pfau wrote:

Am Thu, 08 Jan 2015 10:50:10 -0800
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:


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


These 4x digest variants never occur in real code though:

http://dlang.org/library/std/digest/digest/digest.digest.html is a
class member function. You never use the full name,
it's always instance.digest()

http://dlang.org/library/std/digest/digest/digest.html could be used
with the full name. But ironically the name is not used outside of
std.digest so it's usually not necessary to use the full name.

So it doesn't look nice in the docs but it's not a huge problem when
writing code.


This is a matter common with words that are both noun and verb. Let's 
have a Digest object that digests stuff. I think the review should have 
prompted a name change. -- Andrei





Re: 4x4

2015-01-08 Thread Andrei Alexandrescu via Digitalmars-d

On 1/8/15 12:01 PM, eles wrote:

On Thursday, 8 January 2015 at 16:19:44 UTC, Johannes Pfau wrote:

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


On 1/8/15 4:46 AM, aldanor wrote:
 On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei  Alexandrescu
 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?


I would like to see that wheel start rolling, though.

On my personal list:

std.uni - std.unicode
stripLeft - stripFront
stripRight - stripBack


Let's leave these alone, thanks. -- Andrei


Re: 4x4

2015-01-08 Thread eles via Digitalmars-d

On Thursday, 8 January 2015 at 16:19:44 UTC, Johannes Pfau wrote:

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


On 1/8/15 4:46 AM, aldanor wrote:
 On Wednesday, 7 January 2015 at 07:09:01 UTC, Andrei 
 Alexandrescu

 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?


I would like to see that wheel start rolling, though.

On my personal list:

std.uni - std.unicode
stripLeft - stripFront
stripRight - stripBack