www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6017] New: std.algorithm.remove has a wrong link

reply d-bugmail puremagic.com writes:
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: -------
May 16 2011
next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6017



--- Comment #10 from Jonathan M Davis <jmdavisProg gmx.com> 2011-05-16 11:24:05
PDT ---
Ah. I didn't know that. I wrongly assumed that it wouldn't. That solves the
problem quite nicely then. The obvious solution is then to represent the
hiearchy directly. So, remove gets the anchor #EditOp.remove.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 16 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6017


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eco gnuk.net


--- Comment #11 from Jonathan M Davis <jmdavisProg gmx.com> 2012-01-01 15:36:08
PST ---
*** Issue 7195 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 01 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6017



--- Comment #12 from Brad Anderson <eco gnuk.net> 2012-03-11 15:15:42 PDT ---
Adam D. Ruppe has a pull request that includes a fix for this.

https://github.com/D-Programming-Language/dmd/pull/770

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