for discussion None vs null: vs current:

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> - None is supported as a value in the language just fine - and data
> types like lists and dictionaries and sets have no confusion storing
> None, and also having the ability to indicate that a key is missing etc.
> I'm not sure what historical issues we had, but I see a useful way out
> anyway - see NOT_A_REVISION

The main issues were: we couldn't use None to indicate "no revision
supplied", and if a function failed to return a revision id, it returned
None, which was interpreted as a revision id.

> - NULL_REVISION has semantic meaning, and this makes it very unlike the
> C NULL pointer which has no meaning, and is a wildcard for type - it
> matches any 'object' (in C).

The similarity I see is that both have defined values, (i.e., NULL ==
NULL), but they are used as special values.

> I can see that the intent of our current
> NULL_REVISION is not like NaN, and thus it works like the EMPTY_REVISION
> I'm proposing. I think EMPTY_REVISION has a closer semantic fit to
> people reading the code - folk reading the word NULL do not know /which/
> NULL to interpret it as.

Perhaps ROOT_REVISION, or PROGENITOR?  EMPTY_REVISION's okay, too, but
it doesn't hint at *why* we're using it.

> - that said, perhaps there is a happy medium ground. I propose an
> additional constant - 'NOT_A_REVISION

This sounds good.

> As for delimiters, I dont see our very small selection of constants to
> be a burden, it does not collide with our generated revisionids, and
> revids from other systems can be prefixed: as long as there is not a VCS
> called 'current', there should never be a conflict with 'current:'.
> Using : is simple, clear and easy to read.

The idea was to have a simple rule for making detecting un-storable
revisions.  But endswith(':') is probably a decent rule.

> Current proposal:
> EMPTY_REVISION - 'empty:'
> NULL_REVISION - 'null:'
> CURRENT_TREE_REVISION - 'current:'
> None aka NOT_A_REVISION - ':'

Still not thrilled with reusing 'null:' instead of using a new string,
but I can deal.

> open discussion points:
>  * should we use other delimiters than :.
>  * does NOT_A_REVISION make sense?

The other place we use ':' is in revision specs.  So this would be a
valid spec:

- -r revid:empty:..before:revid:current:

I don't know whether that's worth worrying about.  Certainly, using '/'
could be just as confusing.  Technically, a revision spec is never
permitted where a revision-id may be used, and vice versa, so bzr itself
shouldn't get confused.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEvawc0F+nu1YWqI0RAuGLAJ9ilxjLhxHVIJ0fAHY7SbzeRadx7QCfdCdU
BMN1sq/rWlvUKebWGQcnFSY=
=o/Xm
-----END PGP SIGNATURE-----