This was a very helpful answer. Thank you very much for responding. Cheers,
Colin 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 > total > 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 > readstring > > string(xs...) > > 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 > show(). > > > 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). > > > Regards > > > > Cheers and thanks in advance to all repsonders, > > > > Colin >
