Re: Repair plan for inet and cidr types

Thus spake eisentrp(at)csis(dot)gvsu(dot)edu
> 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.

If it was defined well I would have no problem with it.

> > 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).

I think that's what I meant. I'm just saying that inet::cidr should be
the same as network(inet). Allowing that cast makes a lot of operations
work intuitively.

> 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).

Hmm. It is a subtle difference and I did miss it.

> 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.

I guess what I was really getting at was this.

host OP cidr

where inet would cast to host on one side and cidr on the other. What
we have now is

cidr OP cidr

with both sides casting to cidr. Of course there is no such thing as a host
type so I don't know how we would cast such a thing.

--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.