http://d.puremagic.com/issues/show_bug.cgi?id=6017

           Summary: std.algorithm.remove has a wrong link
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: websites
        AssignedTo: nobody@puremagic.com
        ReportedBy: andrej.mitrovich@gmail.com


--- Comment #0 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2011-05-16 07:47:06 PDT ---
This: http://d-programming-language.org/phobos/std_algorithm.html#remove

points to the enum EditOp; instead of the function remove().

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017


kennytm@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kennytm@gmail.com


--- Comment #1 from kennytm@gmail.com 2011-05-16 08:19:59 PDT ---
It's not technically wrong as the enum value's name is really 'EditOp.remove'... Perhaps those enum values shouldn't be linked.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #2 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-05-16 08:37:43 PDT ---
The way that ddoc generates links needs to be completely rewritten. It needs to be hierarchal, but it's not at all. It acts like it's just linking in a set of free functions, and I believe that it links in the first symbol with a particular name, so if you have multiple documented symbols with the same name, then it's always the first one which gets linked in, regardless of whether that's the one which would be most usefully linked. I do think that having EditOp.remove linked is of value. But the links should be arranged in such a way that their hierarchy is clear, which would mean that the link would clearly be associated with EditOp and that the remove function would have its own link. I believe that this is really a fundamental ddoc problem and not a website problem at all. And I think that the table tha std.algorithm has now is as close to a fix as you're going to get any time soon.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017


Vladimir Panteleev <thecybershadow@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thecybershadow@gmail.com


--- Comment #3 from Vladimir Panteleev <thecybershadow@gmail.com> 2011-05-16 10:29:58 PDT ---
Wouldn't the problem be solved simpler by forcing it to generate unique anchor names for identifiers? I'm not sure how to understand Jonathan's comment about this, but I don't think DDoc actually thinks the two "remove"s are the same identifier.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017



--- Comment #4 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-05-16 10:39:26 PDT ---
Ddoc always generates a link to the first identifier with a given name. How it does that, I don't know. But it makes no attempt to make the links represent any kind of hierarchy. They're purely based on the base names of identifiers and completely ignore whether a particular identifier is actually an enum value or a member of a class or struct. It's designed as if everything were a free function. The way that the links are generated is far too simplistic and needs to be redesigned. In this case, both an enum value and a function have the same name. The enum happens to be first on the page, so it gets the link.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017



--- Comment #5 from Vladimir Panteleev <thecybershadow@gmail.com> 2011-05-16 10:40:49 PDT ---
My suggestion was to simply give one of them the anchor name "remove_2", or something like that.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017



--- Comment #6 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-05-16 10:52:51 PDT ---
They do need unique anchor names, but those anchor names should probably include the hiercharchy in some manner rather than simply having numbers tagged onto them - e.g. #EditOp__remove and #remove. The core problem is that ddoc doesn't care about anything other than the base identifier name. It makes no attempt to worry about the hiercharchy or about duplicate names. And honestly, it shouldn't have to worry about duplicate names, because duplicate names are illegal in the actual code. The duplication occurs because it's effectively treating all of the identifiers as if they were at module-level.

Regardless, unique anchor names will be necessary. But I don't think that simply tacking on numbers is the right way to go about it. The fundamental problem needs to be solved. If you want to see a really bad example of the problem, looke at std.datetime. Several structs in there have the same function name, and the links become pretty useless.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017



--- Comment #7 from Vladimir Panteleev <thecybershadow@gmail.com> 2011-05-16 10:56:42 PDT ---
Yeah, I never said that this is a GOOD solution, but it's a quick and dirty one, and it'll allow linking to stuff in StackOverflow answers until someone fixes it properly ;)

> Several structs in there have the same function name, and the links become pretty useless.

Hmm, so what should be done about this? Serialize the function signature into the anchor name?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017



--- Comment #8 from Jonathan M Davis <jmdavisProg@gmx.com> 2011-05-16 11:11:48 PDT ---
I don't think that we should be linking to every function overload, so the function signature isn't really the issue. It's the hierarchy. So, that needs to end up in the link somehow. So, for instance, if you took the year property that Date, DateTime, and SysTime have in std.datetime, you'd need something like #Date__year, #DateTime__year, and #SysTime__year. It would have to understand the hierarchy and concatenate the pieces of the hiearchy in some manner. __ makes some sense since it's unlikely to ever be the case that you'll end up with underscores at the beginning and/or end of identifiers such that the resulting anchor would conflict with the anchor of an identifier, but exactly what would be picked isn't necessarily all that important. It just needs to be unlikely to result in anchor names which conflict with other anchor names.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6017



--- Comment #9 from Vladimir Panteleev <thecybershadow@gmail.com> 2011-05-16 11:17:40 PDT ---
> __ makes some sense since it's unlikely to ever be the case that you'll
> end up with underscores at the beginning and/or end of identifiers such that

You can put periods in anchor names (MediaWiki uses them to escape other characters, for example), so there's no need for underscores.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------