RE: additions to standard library?

From: Don Syme (dsyme@microsoft.com)
Date: Tue Mar 21 2000 - 22:43:18 MET

  • Next message: Pascal Brisset: "Re: Syntax for label, NEW PROPOSAL"

    > > I've often wondered why languages don't support "extensions" to library
    > > namespaces (and perhaps even to functors). e.g. one could define
    > >
    > > let String.explode s = ....
    > > let String.implode s = ...
    > > let myfun = ...
    >
    > The reason is that it is hard to localise these changes.
    > It isn't acceptable to extend the actual module, since two clients
    > could provide conflicting "extensions". This would break the
    > Open/Closed principle [Meyer, OOSC]

    With regard to conflicts, I don't see that taking a strict approach is
    particularly wonderful. Scoping and locality are, of course, important, and
    of course you still have to be able to know exactly the signatures you are
    compiling against (i.e. the sum of all the extensions you've imported).
    Conflicts can be detected whenever you try to combine extensions (compile
    time or link time) - of course conflicts can occur, but that doesn't mean
    the facility is not very useful when they do not. Effectively the same
    problem occurs when you do this "module List2 = struct include List ... end"
    nonsense, with the horrible proliferation of modules and extensions that
    result, and nightmarish management of extensions. Even in this setting
    there's no way around the potential for conflicts, but, if you assume they
    aren't going to occur (e.g. because of some agreed project management of a
    namespace), then what's the best way forward? I think optimistic is better
    than pessimistic: make the most pleasant system to use, assuming conflicts
    won't occur, but if they do give errors at compile time.

    [ I also think you could implement it so that only conflicts at compile time
    (rather than link time) were significant, by qualifying names in generated
    code according to their compilation units. This gives you quite a high
    degree of locality, and even if conflicts occur between two extensions
    you're using, you can choose, by restricting one signature or another
    appropriately, which parts of which extension you want to make use of. Or
    something like that. ]

    With regard to open/closed, in ML, the signature mechanism provides the way
    to close structures and restrict access. Thus I don't think allowing
    clients to extend the underlying _structures_ contravenes this. I wouldn't
    want to be able to extend _signatures_ that other clients rely upon, unless
    they see and explicitly make use of my extension. And the extender would
    not receive any special rights to access aspects of the structure hidden
    from me.

    Thus, for example, you could still implement an abstract data type and
    restrict access globally via a signature. No one could mess with your data
    type by extending your module, because no one has the privileges necessay to
    access the underlying representation. However they could augment your
    module with their own stuff, which could be very, very useful, as the Set
    functor example indicates.

    In an OO setting, particularly with overriding, the question may be
    different, but that's not quite what we're talking about here. However,
    even Java binary compatibility, for example, specifies ways in which the
    classes you run against may be "richer" than the ones you compiled against.
    The question is just one of who gets to extend, what rights they have, and
    how this maps onto the namespace facility of a language.

    Cheers!
    Don

    -----Original Message-----
    From: John Max Skaller [mailto:skaller@maxtal.com.au]
    Sent: 21 March 2000 21:08
    To: Don Syme
    Cc: 'caml-list@inria.fr'
    Subject: Re: additions to standard library?

    Don Syme wrote:
    >
    > I've often wondered why languages don't support "extensions" to library
    > namespaces (and perhaps even to functors). e.g. one could define
    >
    > let String.explode s = ....
    > let String.implode s = ...
    > let myfun = ...

    The reason is that it is hard to localise these changes.
    It isn't acceptable to extend the actual module, since two clients
    could provide conflicting "extensions". This would break the
    Open/Closed principle [Meyer, OOSC]

    -- 
    John (Max) Skaller, mailto:skaller@maxtal.com.au
    10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
    checkout Vyper http://Vyper.sourceforge.net
    download Interscript http://Interscript.sourceforge.net
    



    This archive was generated by hypermail 2b29 : Wed Mar 22 2000 - 17:09:33 MET