Re: Repair plan for inet and cidr types

On Tue, 4 Jul 2000, D'Arcy J.M. Cain wrote:

> I'm not sure I understand why this is necessary. I can see not allowing
> cidr ==> inet conversions but inet ==> cidr can be done as it is a matter
> of dropping information - the host part.

Automatic casts should not lose information. How would you feel if floats
were automatically rounded when you store them into int fields? I think
this is an important principle in any type system.

> Then let's define that as the meaning of "inet1 << inet2" i.e. define
> the << operator between inet types as meaning "tell me if inet1 is in
> the same network as inet2."

Again, let the user say what he wants: inet1 << network(inet2).

Also note that "is inet1 in the same network as inet2" is different from
"is inet1 contained in the network of inet2" (which is what it does now).
The operator you defined is symmetric (if inet1 is in the same network as
inet2, then inet2 is also in the same network as inet1), whereas the << is
antisymmetric. In fact, AFAICT, the operator you defined doesn't exist
yet, although it perhaps should.

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e(at)gmx(dot)net 75262 Uppsala
http://yi.org/peter-e/ Sweden