[bind10-dev] A plea for Name() rather than Name(".")

[JINMEI Tatuya / 神明達哉]

At Tue, 16 Feb 2010 05:25:02 -0600,
Michael Graff <explorer at flame.org> wrote:

> At the last f2f meeting I really wanted to have a way to create but not
> initialize a Name class.  This was because at the time of creating it I
> did not yet know what I wanted there.  I was told this is a bogus
> request and we should not need this, because it would cause problems in
> rendering (exception) and the class should at all times be consistent.

I don't know who told that (= "bogus request"), or that was probably
spoken in the International English and you translated it into
American English with different meaning:-)

At least about me, what I tried to say was that it was a tradeoff
issue between safety and convenience, and while I understand the plus
side of the latter I was not convinced of losing the former for the
latter based on the need I heard.

I also gave some more detailed explanation on this issue at the
bind10-dev list:
https://lists.isc.org/pipermail/bind10-dev/2010-January/000444.html
(no one responded to this message though)

(The following basically rephrases what I tried to say in the previous
message)

In fact, one of the main purposes of explicitly prohibiting an empty
Name is to avoid one to define an empty name object "because at the
time of creating it one did not yet know what's wanted there".  As a
general matter, I believe we all agree that variables must be defined
and used as local as possible, because the longer a variable exists
the more likely we suffer from a subtle bug that its value magically
changes while being used.  It also tends to lead to a bug of using an
uninitialized variable, including "implicitly initialized", where a
variable is initialized with an ad hoc default value such as "0"
(intending to fill it with a meaningful value later) and is
accidentally used before full initialization.

Unfortunately C doesn't have a strong support for prohibiting such an
error prone style in that
- (until C99) variables must be defined at the beginning of a function
- we cannot enforce how a variable is initialized (i.e. as long as the
  type matches we can basically assign any value to a variable of that
  type; we can also define a structure variable and only partially
  initialize its content)
and since we cannot prohibit it at compiler/language level it anyway,
it may make sense to use that programming style for the convenience of
programmers.

In C++, however, we have language support in this area:
- variables can be defined wherever appropriate
- we can avoid a variable (of a class) to be initialized in an invalid
  way by explicitly specifying the interface of constructors (or by
  explicitly hiding the constructor)

If we impose a restriction on how a variable can be initialized using
these language level tools, it will require the programmer to think
about how/where to define and use it more seriously because otherwise
it wouldn't compile.  It's certainly inconvenient for a programmer,
especially at the code writing time, but it will make the code more
robust, safer, and easier to debug.

I don't deny all cases where a object has some "null" state.  But if
the reason is "we don't know what it should be when we define it", IMO
it means that point is too early to actually define the variable.
Regarding the specific desire of how we'd use an empty name, I pointed
out that it's essentially not really an "empty name" but the state of
"we have no matching name for a give search key", and showed a
possible alternative (and IMO better) approach to address the
requirement in the previous message.  Evan actually seemed to adopt
this way in the data source/auth server development branch- although I
don't know if it's a coincidence or because he was convinced about the
argument or because he was just tired about arguing on this topic.

Finally, even if we agree about the safety argument in principle, if
the enforced programming style makes developers feel so uncomfortable
that they won't use the library, that's not the end result I wanted
either.  Hopefully we can get more feedback from third party
developers who try this library to see if this restriction provides a
reasonable balance between convenience and safety or if it's too
restricted.

As I said above, my understanding is that this is a tradeoff issue.
As with any tradeoff matter, it's not surprising if you're still
unconvinced while I'm also not convinced about the need for an empty
name object.  If that's the case, I don't have a good idea of how to
break the tie, but I'll at least try to suggest how to go about the
restriction for each specific usage, just like I did for the name
match example in my previous message.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.