MOO-cows Mailing List Archive

[Prev][Next][Index][Thread]

Re: Quick Question [ANSI]



>  At 11:59 PM 9/5/95, Ahn Jinsu wrote:
>  >  This patch adds new built-in function 'cnotify()'. It works exactly like
>  >'notify()' built-in, except that it interprets '^'ed character into control
>  >character.
...
>  >  cnotify(this, "^[[;H^[[J");   => clear the screen
>
>  I personally don't think this is a very good idea - If someone typed a ^ in
>  a say/emote/something similar (Like if they said '5^3 == 125', it would be
>  interpreted as a control character - Not good. :)
>  Using a more obscure character might be better.

It should work well enough.

Note that any character can potentially have the same problem; sooner or
later some other use of it will stomp on you.  Using an obscure character
and hoping that no one else will have some other use for it is just asking
for trouble.  This is why it's important to

(1) when writing a routine that makes use of escape characters in
    this way, remember to include a means of quoting the escape character
    (in this case, "^^").  The general principle is that you want a
    string with escapes to be able to represent ANY string.

(2) keep straight which verbs are expecting/returning escaped-strings
    and which are expecting raw strings (and likewise keep straight
    which properties... etc.), quoting the raw strings WHEREVER
    they're being fed into places expecting escaped strings, even
    if it seems unnecessary.  E.g., the guts of the special
    blinking_announce verb would have something like

cnotify(whoever, blinkie_on + cquote(announcement) + blinkie_off);

    rather than

cnotify(whoever, blinkie_on + announcement + blinkie_off)

    cquote() is the routine to turn all ^ chars into ^^.
    Now `announcement' can be absolutely anything.

    It's basically a type-checking problem, but the MOO type system
    won't help you, so you have to document like crazy.

If anything you may want to use a non-obscure character that's already
being widely used (e.g., \, or maybe A) so that you'll get into the
discipline and uncover your mistakes far more quickly.  If you use %,
you'll have the added bonus of finding all of the places people forgot
to use $string_utils:pronoun_quote().

Anyway if one is going to insist on sending out weird ASCII codes, this
approach (i.e., keeping the strings in escaped form and only translating
them at notify-time) is at least safer in that you don't have to worry about
what bizarre things might happen to your DB due to unexpected characters
(e.g., \0, \n) appearing in literal strings.

I'd still be worried about what ^@ will do to routines in the network
code that might be expecting null-terminated strings.  With luck,
there won't be any.  You'll have to test to see if the B in
`cnotify("A^@B")' makes it through (pray that the clients don't get
confused either).

Finally, you'll need a solution to the termcap problem, i.e., the fact
that ^[[;H^[[J won't clear *my* screen or anything approaching a majority
of the screens out there.






Home | Subject Index | Thread Index