On Sunday, April 26, 2015 at 1:18:40 AM UTC-4, Jeff Bezanson wrote:
>
> Scott-- yes! If BetterA imports and extends a function from A, it is
> exactly the same function object. A.func and BetterA.func will be
> identical. Problems only enter if A and BetterA were developed in
> total isolation, and the authors just happened to pick the same name.
>
> The way to go here would be to have the DocumentDB module define an
> interface, and then both MongoDB and TokuMX extend it. What I don't
> get is that elsewhere in your argument, you seem to say that
> coordinating and agreeing on an interface is a non-starter. But I just
> don't see how you could talk to both MongoDB and TokuMX with the same
> code unless they agreed on an interface.
>
You are missing a couple points here:
1) Why would MongoDB and TokuMX coordinate and agree on an interface?
They are competitors. TokuMX has made their code compatible with
MongoDB's interface,
and MongoDB may very well decide to add things that will break TokuMX
in the future.
2) While they might have compatible interfaces, because TokuMX decided to
copy it,
they are not likely to do anything together.
Now consider `connect`. This might be common to both DocumentDB and
> SQLDB. Is it similar enough that it should go in an even more abstract
> interface GeneralDB? I'm not sure, but I think this is exactly the
> kind of interface design process that happens in any OO language. In
> Java, you can have a `connect` method whether or not you implement a
> `Connectable` interface. But only if you explicitly refer to the
> Connectable interface will you be able to work with code that requires
> it. I think the same kind of thing is happening here. You can just
> write a `connect` function, or you can say `import
> Connectable.connect` first, in which case you will be extending the
> "public" `connect` function.
>
Here is the big stumbling block - you assume that the writers of these
packages, whose names have collided because they
are doing similar, but not identical names, will be able to go back and
come up with another interface,
and that there should be one true meaning for a particular name.
Since there is already a "connect" in Base, you are saying that nobody else
can have a different interface that uses that name?
Also, let's say I had a "getsockname" in my DB access code, to get the name
of the socket used by a connection...
Yesterday, people using my package would suddenly get errors, because
#11012 added their own getsockname to Base.
Not good at all, IMO.
> On Sun, Apr 26, 2015 at 12:25 AM, <[email protected] <javascript:>>
> wrote:
> > The situation I was describing is that there is:
> >
> > module A
> > type Foo end
> > f(a::Any) ...
> > f(a::Foo) ...
> >
> > which expects f(a) to dispatch to its ::Any version for all calls where
> a is
> > not a Foo, and there is:
> >
> > module B
> > type Bar end
> > f(a::Bar) ...
> >
> > so a user program (assuming the f() functions combined):
> >
> > using A
> > using B
> >
> > b = Bar()
> > f(b)
> >
> > now module A is written expecting this to dispatch to A.f(::Any) and
> module
> > B is written expecting this to dispatch to B.f(::Bar) so there is an
> > ambiguity which only the user can resolve, nothing tells the compiler
> which
> > the user meant.
> >
> > Cheers
> > Lex
> >
> >
> > On Sunday, April 26, 2015 at 12:00:50 PM UTC+10, Michael Francis wrote:
> >>
> >> I don't think Any in the same position is a conflict. This would be
> more
> >> of an issue if Julia did not support strong typing, but it does and is
> a
> >> requirement of dynamic dispatch. Consider
> >>
> >> function foo( x::Any )
> >>
> >> Will never be chosen over
> >>
> >> Type Foo end
> >>
> >> function foo( x::Foo )
> >>
> >> As such I don't get the argument that if I define functions against
> types
> >> I define they cause conflicts.
> >>
> >> Being in the position of having implemented a good number of modules
> and
> >> being bitten in this way both by my own dev and by changes to other
> modules
> >> I'm very concerned with the direction being taken.
> >>
> >> I do think formalization of interfaces to modules ( and behaviors)
> would
> >> go a long way but expecting a diverse group of people to coordinate is
> not
> >> going to happen without strong and enforced constructs.
> >>
> >> As an example I have implemented a document store database interface,
> this
> >> is well represented by an associative collection. It also has a few
> specific
> >> methods which would apply to many databases. It would be nice to be
> able to
> >> share the definition of these common interfaces. I don't advocate
> adding
> >> these to base so how should it be done?
> >>
> >
>
