使用字符串而不是符号:好还是坏？

Question

通常情况下,我发现自己处理表单的功能选项列表(或更常见的替换列表){foo->value,...}.当foo已经在$ Context中有一个值时,这会导致错误.一种显而易见的方法是使用字符串"foo"而不是符号:{"foo"->value,...}.这很有效,但似乎让我知道的一些经验丰富的LISPers感到愤怒,他们惩罚我混淆符号和字符串并告诉我使用内置的引用结构.

虽然这是绝对有可能写的是避免冲突,而不使用字符串代码,它往往显得更麻烦比它的价值.另一方面,我没有看到太多{"string"->value}类型替换规则的例子.所以问题是 - 这是一种可以接受的使用模式吗？..是否有特别合适的情况？......应该避免哪里？

Answer 1

在我看来(免责声明 - 这只是我的意见),最好避免使用字符串作为选项名称,至少对于函数中的"主"选项.字符串OTOH完全可以作为设置(选项的rhs).这并不是说您不能使用字符串,就像您指出的那样.也许,它们可能更适合子选项,并且它们以这种方式被许多系统功能使用(通常是"超级功能",例如NDSolve,可能在选项中有子选项).我在使用字符串时遇到的主要问题是它们减少了系统和用户的内省功能.换句话说,发现一个具有字符串名称的选项比使用符号名称的选项更难 - 对于后者我只能检查包中符号的名称,并且符号选项名称也有使用消息.您可能还希望自动执行某些操作,例如编写在包中查找所有选项名称的实用程序等.当选项名称是符号时,更容易做到,因为它们都属于同一个上下文.也很容易发现某些选项没有使用消息,可以通过编写实用程序功能自动执行此操作.

最后,您可以更好地防止类似选项名称的意外冲突.可能是,许多选项序列被传递给您的函数,有时它们可​​能包含具有相同名称的选项.如果选项名称是符号,则完整符号名称将不同.然后,您将同时获得阴影警告,同时保护 - 仅使用正确的选项(完整)名称.对于字符串,您不会收到任何警告,并且可能最终使用不正确的选项设置,如果具有错误设置的复制字符串选项名称(例如,用于不同的函数)恰好在列表中的第一位.这种情况更有可能发生在较大的项目中,但像这样的错误可能很难捕捉(这是猜测,我从来没有这样的情况).

至于可能的冲突,如果你遵循一些命名约定,例如选项名称总是以大写字母开头,加上将大部分代码放在包中,并且不启动变量或函数名称(对于交互式会话中的函数),大写字母,那么你将大大减少这种碰撞的机会.此外,您应该Protect在定义选项名称时或在程序包的末尾添加选项名称.然后,碰撞将被检测为阴影的情况.避免阴影OTOH是一般必需品,因此选项的情况在这方面并不比函数名称等更特殊.