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


  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

Reply via email to