Date: Sun, 24 Jan 1999 15:04:42 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mikhail Teterin <mi@kot.ne.mediaone.net> Cc: current@FreeBSD.ORG Subject: Re: sysctl oids (was: Re: kvm question) Message-ID: <199901242304.PAA05248@apollo.backplane.com> References: <199901242244.RAA04500@kot.ne.mediaone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a silly argument. Unless the operation in question
needs to be run a thousand times a second, a string is just
fine as a lookup mechanism. Duh. Besides, you can always
cache the translation.
-Matt
Matthew Dillon
<dillon@backplane.com>
:Julian Elischer once stated:
:
:=> Nonsense. There are plenty of contexts in which a number makes far
:=> more sense than a name -- pretty much anything in any network stack
:=> other than Chaosnet, for example. If any of us ever make good on the
:=> threat of SNMP integration, having fixed numerical identifiers will
:=> be a requirement.
:
:=SNMP will require a translation layer anyhow.. numbers cannot and
:=should not be used. They are not easily maintained in the face of
:=multiple external modules being dynamically loadable.
:
:=That is at least my opinion.. you may and do disagree. I guess you will
:=say that numbers are just as dynamic, etc.etc. well I just think that
:=in the REAL WORLD, as opposed to the theoretical world, names (which
:=require no co-ordination between authors), are a better choice than
:=numbers, which require some central naming authority.
:
:Pardon my intrusion, but I strongly dislike the very thought about
:my computer looking-up the same string more then once or twice. If it
:counts -- I'd take a number over a string anytime anywhere other
:then in a documentation.
:
: -mi
:
:To Unsubscribe: send mail to majordomo@FreeBSD.org
:with "unsubscribe freebsd-current" in the body of the message
:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901242304.PAA05248>