[Guido]
> Yes, but in the mean time the fact that it's buggy doesn't bother me
> at all. Let it be as buggy as it always was -- that's one more reason
> to stop using it! :-)
I think that's unsustainable in this specific case: stringobject and
stropmodule contained several utility functions with the same names that
clearly started life as identical code. Over time they got out of synch, and
when they punched me in the face today, I had no idea which was "right" and
which "wrong". Turned out they both had the same bug, and the clearest way
to fix it in stringobject.c without leaving a more inconsistent x-module mess
was to bring the once-common utility routines back into synch.
As /F said, though, the mymemreplace() approach is inefficient and "should
be" replaced wholesale. If that's done in stringobject.c alone, great, then
I won't care about the legacy routines in stropmodule.c either. What I can't
abide is having one copy of a function in the codebase work and a clone of it
not work -- unless you can keep the undocumented history of both in your mind
at all times, you're just as likely to bump into the broken one first when
searching the code base, and if you're unlucky never even realize it is "the
broken one" (or, if you're lucky, bump into the good one too, and then pee
away time trying to understand the differences).
i-have-garbage-in-my-kitchen-too-but-i-put-it-in-a-bag-so-i-don't-
eat-it-by-mistake<wink>-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4