George Greer wrote:
>
> On Tue, 10 Jul 2001, Peter Ajamian wrote:
> >
> >actf(TO_CHAR, 0, "$cYou tickle $n.\r\n", ch, tch);
> >actf(TO_CHAR, 0, "$c$n tickles you.\r\n", tch, ch);
> >actf(TO_NOTCHAR, 0, "$c$c$n tickles $n.\r\n", ch, tch, ch, tch);
>
> Uuurk! I'm trying to avoid heart attacks, thanks. :)
Any time ;)
> You've just made the sending string encode a parameter. Why stop there? We
> can just do:
>
> actf("TO_ROOM:0:$cYou tickle $n.\r\nTO_CHAR:0:$c$n tickles you.\r\n"
> "TO_NOTCHAR:0:$c$c$n tickles $n.\r\n", ch, tch, tch, ch,
> ch, tch, ch, tch);
>
> Then we can get rid of all those three act() statements and compress it all
> down to one easy-to-read printout. Right?
Hey, great idea! (j/k)
> (Please don't say yes.)
Oops! ;)
> >> That's a bit of abuse of variable arguments, no?
> >
> >How so?
>
> We're not actually passing the argument to the format, we're just including
> it because no other information was given as to whom to send the string
> to. Whenever someone is actually the target, the argument is omitted
> because it is included already. It seems an awfully "special" case to be
> required that way.
I quite a gree which is why I wanted to spell out the targets in the
format as per my suggestion above. The intention is to allow for a
variable number of targets (thereby increasing flexibility) but not to
fall into a trap of trying to intuitively guess what the target is from
the other parameters. I think that ideally the target(s) should be
spelled out seperately from the parameters to avoid such nastiness. If
you want to avoid spelling out the number of targets in the format then
pass an extra arg for it (int targets) or simply use a fixed number of
targets (2 or 3) with NULL indicating unused targets such as that
proposed by DAK. My thinking behind using format specifiers, though is
to allow for different types of targets (maybe an object, room or zone).
> I'm not exactly sure what to do with act() at the moment. It's a rather
> general function...
Well, I imagine (no, I'm not counting) that a lot of current patches and
snippets use act(). So it would be folly to break compatibility with
this function. Hence the reason I initially proposed actf(). My
suggestion for act() is depreciation and eventual elimination. I think
three stages are warranted:
1. Depreciate act(). Place warnings (pleas) to not use the funtion
everywhere it is prototyped. Convert all internal cals to act to the
equivelent calls to actf() and then modify act to mudlog it's usage with
a SYSERR.
2. After a suitable amount of time has passed disable act() by
enclosing it and it's prototypes with #if USE_OLD_ACT/#endif and #define
USE_OLD_ACT 0.
3. After an additional suitable amount of time has passed eliminate
act() alltogether.
> The only real trouble cases I can think of are
> queries like:
>
> Send to all indoor rooms in the zone.
> (TO_ZONE | TO_INDOOR | TO_NOT)
> Send to all outdoor rooms not in the zone.
>
> Oops, which is the case described by the bitmask?
I like DAKs idea for this, and so I won't elaborate any further.
> Other fun ones are the case of sending to a character not included in the
> format specification, where's the argument goes? If we include it as a
> fixed parameter, we'll need it everywhere. If we include it as an argument
> without being in the format then we've just made a rather huge
> inconsistency with the arguments based on the format. (Now, if it wasn't
> based on the format, I wouldn't have a problem with the various arguments
> thrown in.)
I think I already addressed that, but to reiterate, it should be very
clear what args represent targets, and what args are for text insertion
or modification. I think it would be unwise and confusing to try to use
the same arg for both.
> > >> Not that we could use GCC
> > >> printf format checking anyway due to handling $-style parameters
> > >> ourselves.
> >
> >Hrmmm, I see what you mean. I can't help but think there's got to be a
> >way to extract or change parameters from the list and pass the balance
> >on to the vsprintf() function.
>
> Sure we could, but the compiler still couldn't check the arguments at
> compile time. It only recognizes "%foo = argument", not "$foo = argument"
> as well.
Oh, I see, you want compile-time checking. Well, unless we pull some
really imaginative macro stunts I don't see how that's possible. But I
think runtime checking should be fine.
> >Too bad we have to stay Windoze (and others) compatible, GNU has
> >facilities to specify our own printf() conversion functions. Do Windoze
> >and other platforms have similar functions? It _could_ be made to work
> >via that route.
>
> I'm not sure the printf() would have enough information to determine things
> like visibility.
Since the customized format specifiers are done via functions (at least
that's what I picked up in my brief glance through the info pages) we
can write the functions so they do, in fact, have all the info they
need.
Regards, Peter
--
+---------------------------------------------------------------+
| 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