By the way: what is wrong with having length(Boat) length(Vacation) length(Membership) length(Stay) length(Nose)
? I think the answer is NOTHING. So why should length() take on a definite (and fixed) meaning in the Base module? Julia already SUPPORTS this, so why limit this when it could be a good thing? P On Tuesday, January 13, 2015 at 4:06:30 PM UTC-8, Petr Krysl wrote: > > Mauro, > > On Tuesday, January 13, 2015 at 1:45:36 PM UTC-8, Mauro wrote: >> >> >> I don't think it is good practice to add unrelated methods to generic >> functions in Base. A guide-line could be to check whether your methods >> matches up with the help text, if so, add it to Base.count otherwise >> not. If not, either give it a different name or do not export it, so >> the user has to fully qualify it MyMod.count. >> > > I generally agree with this sentiment, but my libertarian core rebels > against the notion that the writer of the software that I use gets to > decide the meaning of the words that are used as identifiers of functions > and such. Many common concepts, such as length, angle, domain,… will > eventually be taken and therefore unavailable to future software > developers. (Of course I realize that they are still available as > qualified names.) > > More importantly, since the possibility of writing totally unrelated > methods for a given generic function cannot be eliminated, I believe that > even the double import of a generic function resulting in merged methods > should be allowed. It would provide for uniformity, as even this > restriction can be easily bypassed by defining a dummy generic function in > the environment that "uses" two modules that export methods for this > function. Not allowing repeated imports does not accomplish anything > except that it gets in the way. > > Petr > > >> it. >> >
