This was a very helpful answer. Thank you very much for responding.
On 16 October 2016 at 20:23, Milan Bouchet-Valat <nalimi...@club.fr> wrote:
> Le samedi 15 octobre 2016 à 20:36 -0700, colintbow...@gmail.com a
> écrit :
> > Hi all,
> > Twice now I've thought I had overloaded the appropriate functions for
> > a new type, only to observe apparent inconsistencies in the way the
> > new type behaves. Of course, there were no inconsistencies. Instead,
> > the observed behaviour stemmed from overloading a function that is
> > not at the bottom of the function chain. The two examples where I
> > stuffed up were:
> > 1) overloading Base.< instead of overloading Base.isless, and
> In this case, the help is quite explicit:
> help?> <
> search: < <= << <: .< .<= .<<
> <(x, y)
> Less-than comparison operator. New numeric types should implement this
> function for two arguments of the new type. Because of the behavior of
> floating-point NaN values, < implements a partial order. Types with a
> canonical partial order should implement <, and types with a canonical
> order should implement isless.
> > 2) overloading Base.string(x) instead of overloading Base.show(io,
> > x).
> This one is a bit trickier, since the printing code is complex, and not
> completely stabilized yet. Though the help still gives some hints:
> help?> string
> search: string String stringmime Cstring Cwstring RevString RepString
> Create a string from any values using the print function.
> So the more fundamental function to override is print(). The help for
> print() says it falls back to show() if there's no print() method for a
> given type. So if you don't have a special need for print(), override
> > My question is this: What is the communities best solution/resource
> > for knowing which functions are at the bottom of the chain and thus
> > are the ones that need to be overloaded for a new type?
> In general, look at the help for a function. If there's no answer
> (which is a most likely a lack in the documentation which should be
> reported), look for it in the manual. The latter can always be useful,
> even if the help already gives a reply.
> But documentation is perfectible, so do not hesitate to ask questions
> and suggest enhancements (ideally via pull requests when you have found
> out how it works).
> > Cheers and thanks in advance to all repsonders,
> > Colin