On Sun, 7 Oct 2001, Gerd Stolpmann wrote:
> You can use objects as keys. The object ID is used in this case. I.e.
> obj1 = obj2 <=> obj1 and obj2 are the same object. Of course, objects are not
> compared component by component.
>
> I think the comparison by components does not make sense because there is no
> way to find out whether two mailbox references mean the same mailbox or not.
> Maybe the object ID is better. But I am undecided.
>
> Testing: It is possible to define printers for objects.
I forgot that objects could check for equality on themselves. This does
make the objects reasonable to deal with, with only a little more work for
testing. In that case, I think I favor the object approach because of the
ease of extensibility in the future
For consistency with the message structures, there should be a method to
access the original string for the address. I'm not sure how this should
behave in the presence of mutability, or for addresses that are created
programatically. One issue to consider is that there are many obsolete
forms of addresses that must be supported for backwards compatibility, but
must not be generated by new programs. Any suggestions?
One option is to provide a validate method, another could be to have the
printer simply ignore certain informate (like the route).
> > type mailbox = {
> > name: string option;
> > route: string list;
> > spec: addr_spec;
> > }
>
> Better: mb_name, mb_route, mb_spec. This avoids name clashes.
There are definitely two camps to this in the Caml community. I find
myself opening the Unix module because the name fields have been prefixed.
On the other hand, I probably wouldn't open the module if I didn't have to
duplicate prefix information. Being able to avoid this issue is a
definite benefit of the object system.
Patrick
|
