Just to clarify my position on this issue, I am not advocating for change in Base, nor am I particularly worried about the size of Base. I am simply pointing out that Base has defined a large array of verbs ( which all props to the language are generally very consistent.)
If the majority of what you are doing is extending the verbs provided by Base the world is a nice place, but you have no idea until runtime which function will be called in which package. *I am very happy with this behavior.* [ I'm going to use the word 'surprising' below, I am defining this as the opposite of 'behavior of least surprise' ] If I define verbs for my package which are not in Base then I either have to export them or prefix them with a namespace. If I export them then I risk future breakage even if the verbs are called only against types which I define. This is surprising behavior. I agree that this behavior is consistent with Base, but Base by nature of its universal inclusion occupies a rarefied space which claims the initial set of verbs. Where things start to become more surprising is when a new user defines a function 'get' in their namespace and it is not defined as 'Base.get'. Clearly this is just a difference to be learned but I'd argue it has the potential to make adoption at a larger scale harder. The masking of Base.get is not intuitive, though is consistent with the definition of the language. Additionally for types that the user has defined it is also not ambiguous which version of 'get' to call. *** I am not sure whether I like this or not, it is just an observation *** My other point about Base is that one could argue (based on many of the arguments in this thread) that Base should be subdivided into separate Modules which force users to qualify namespaces, preserving the meaning of a verb and ensure that the user understands which function is being called. *** I am NOT advocating for this ***. One item that has been raised a number of times is plot vs plot against the base type vector. In these cases I see no reason why plot should not be required to be qualified. There are two conflicting methods which can not be distinguished by the runtime. So the crux of the issue is that certain choices in the language, specifically with modules and namespaces relegate user defined verbs to be second class even when there is no calling ambiguity. What I fear is that people will incorrectly overload the existing verbs provided by Base simply to avoid the name spacing issue, I can already see my style of coding going in that direction and I am not 100% sure that is a good thing. On Thursday, April 30, 2015 at 5:18:23 PM UTC-4, Stefan Karpinski wrote: > > On Thu, Apr 30, 2015 at 12:19 PM, Michael Francis <[email protected] > <javascript:>> wrote: > >> My goal is not to remove namespaces, quite the opposite, for types a >> namespace is an elegant solution to resolving the ambiguity between >> different types of the same name. What I do object to is that functions >> (which are defined against user defined types) are relegated to being >> second class citizens in the Julia world unless you are developing in Base. >> For people in Base the world is great, it all just works. For everybody >> else you either shoe horn your behavior into one of the Base methods by >> extending it, or you are forced into qualifying names when you don't need >> to. >> > > There's nothing privileged about Base except that `using Base` is > automatically done in other (non-bare) modules. If you want to extend a > function from Base, you have to do `Base.foo(args...) = whatever`. The same > applies to functions from other modules. The Distributions and StatsBase > packages are good examples of this being done in the Julia ecosystem. What > is wrong with having shared concepts defined in a shared module? > > >> 1) Didn't that horse already bolt with Base. If Base were subdivided into >> strict namespaces of functionality then I see this argument, but that isn't >> the case and everybody would be complaining that they need to type >> strings.find("string") >> > > I don't understand how any horses have bolted – Base is not particularly > special, it just provides a default set of names that are available to use. > It in no way precludes defining your own meanings for any names at all or > sharing them among a set of modules. > > 2) To me that is what multiple dispatch is all about. I am calling a >> function and I want the run time to decide which implementation to use, if >> I wanted to have to qualify all calls to a method I'd be far better off in >> an OO language. >> > > This is exactly what happens, but you have to first be clear about which > function you mean. The whole point of namespaces is that different modules > can have different meanings for the same name. If two modules don't have > the same meaning for `foo` then you have to clarify which sense of `foo` > you intended. Once you've picked a meaning of `foo`, if it is a generic > function, then the appropriate method will be used when you call it on a > set of arguments. >
