On Sat, 21 Jul 2001, Del wrote:
>George Greer wrote:
>>
>> - sprintf(buf, "You say, '%s'\r\n", argument);
>> - send_to_char(buf, ch);
>> + send_to_char(ch, "You say, '%s'\r\n", argument);
>>
>> These changes make the code unstable? The majority of the changes will be
>> no-brainers. Only a few places have any sort of reworking that will take
>> thinking to confirm.
>
>I didn't say the changes that were put in has anything to do with making the
>code unstable, but does the changes removes instability?
Yes. No longer do you have to worry about corrupting your variables on
accident or using a variable you didn't intend to.
>This is my point, you have changed the usage of send_to_char which will
>undoubtfully cause havoc for those who have modified code and want to update
>to the latest bpl. Having to manually go through every instance of modificaton
>and changing every send_to_char to fit.
Search & replace. Make the computer work for you, not vice versa. That's
how I did the majority of the changes. Then I searched for 'sprintf' to
find the instances I could improve the code by eliminating buffers. Some
places (do_stat_*() comes to mind) are rife with abuse but I didn't have to
eliminate the buffers there. I could've just taken the easy way out and
left the buffers there.
>Would it not have been wiser to add a function such as SEND_TO_CHAR so
>all previous uses of send_to_char from older
>patches/modifications/snippets/whatnot can still be used.
Not with send_to_char() keeping the same name. If this was C++ I probably
could have.
>Every single patch that has a send_to_char will now have to be modified in
>order to work with this new version (Not saying that it didn't in the first
>place). oh boy.. It doesn't matter what happens next, every newbie will be
>screaming left and right about putting in patches.
Didn't we just have a discussion on this last week? What a great field
experiment. :)
>(Or am I missing something here that would still allow snippets/patches
>to go in without too much trouble?)
The compromise would've been:
void send_to_char(const char *format, struct char_data *ch, ...)
which would have been backwards compatible, if you don't mind violating
every rule about "principle of least suprise" and "consistency."
The old way was bad. The new way is good. There really isn't a middle
ground that isn't bad as well:
1) send_to_char(format, ch, ...)
Compare: sprintf(target, format, ...), fprintf, sscanf, etc.
Also, is 'ch' supposed to be in the format? It is for every other
function of that sort.
2) send_to_char(format, ch) + send_to_charf(ch, format, ...)
Now we have two functions doing the same work. Which should we use?
Should we continue using sprintf() in some places to feed to
send_to_char() or just throw it in one go to send_to_charf()? The
non-variable behavior of send_to_char() encouraged bad code and
leaving it in the baseline won't solve the problem we need to.
3) send_to_char(ch, format, ...)
Works as expected. Code is cleaner. Everybody has to do a one-time
search & replace change on their existing code or a patch added.
This isn't change for the sake of change. This is good change, you just
don't realize it yet.
--
George Greer
greerga@circlemud.org
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST