Proposing a convention for null ObjectPaths

[Ryan Lortie]

Hi.

Sorry for taking so long to reply.  I'm not normally on the list, but
this email was pointed out to me as something that I might be interested
in replying to.

I have a number of problems with this proposal.

First: I believe that type safety can exist in dbus.  There is a lot of
talk about "you can send whatever type you want over the wire", but if
you write your server-side method dispatch code something like:

{
  if (is_method ("foo") && has_signature ("..."))
    return do_foo ();
  else if ...
    ...

  return not_handled;
}

then you have quite a bit of type safety -- assuming that your types
properly constrain the values that can be sent.

For this reason, I believe that the types that we use should be as
tightly constrained as possible.

If implemented, your feature would incite people to abuse "variant" in
new and horrible ways.  People would send their "integer or null" values
as a variant that contains either an integer or a "null" object path.

This is a disaster in terms of expected contents of a message since you
could really send absolutely anything you want.  If what you want to
send is one of only an integer or a "null" then you should express this
with the type.

I think that this misuse is caused by treating as a special case
something that really is not.

...

At my university a few years ago there was a Microsoft presentation of a
language called Spec#.  It was C# with some static safety guarantees.

One thing that it introduced was the concept of a non-null reference
(ie: an object reference _must_ be valid).

Did this feature ever make it into C#?

If it did, then this is what I see:

Object references come in two flavours:
  those which must have an actual object
  those which may be 'null'

Primitive types (like integers) come in two flavours:
  those which must have an actual value
  those which may be 'null'

This is really the same thing.

What I'm getting at here is that I don't think that objects are any more
"nullable" than anything else.  For everything -- sometimes you want
nullability and sometimes you don't.  Currently the type "object path"
means "a non-null reference to an object".

A much better solution, I think, is to introduce "Maybe" types.  Any
possible type in the type system can be made nullable.  The mechanics of
how this would work were discussed briefly at GUADEC:

A new type symbol, "m" is introduced that works like "a" does for
arrays.  If you want to send an integer or null, you use the type "mi"
which can take on the following values:

 * Nothing
-or-
 * Just [any valid value for the type "i"].

This will map quite directly to C# (and particularly so if you do, in
fact, have non-null reference types).

In the case that C# lacks non-null reference types then all C#
references should really just all be mapped to "maybe object" dbus types
since, really, this is what they actually are.

...

I believe that introducing the ability to send 'null' in an object path
at this point is a rather bad idea.

 * if 'maybe' is implemented, then it is redundant

 * it encourages variant abuse

 * it reduces the expressiveness of the type system:
     ie: we forever lose our "non-null object path" type.

 * 'maybe' is actually a much nicer fit for C#

...

Cheers