For the record, a workable solution, at least for this particular code: I 
pass all output through wrapout() at the outermost output call. The object 
to be printed is traversed recursively. All types fall through except for 
the handful that I want to change. Each of these is each wrapped in a new 
type. I extend Base.show for each of these wrapper types. This seems pretty 
economical and  robust and works across versions. The wrapper types are 
only introduced upon output, the rest of the code never sees them.

This works because the code uses a customization of the REPL, and several 
instances of print, warn, string, etc. I make a new top-level output 
function for the REPL that uses `wrapout`. I also  generate wrappers for 
each of print, etc. that map `wrapout` over all arguments. A developer is 
expected to use the interface provided rather than `print` etc. directly.  
The user doesn't even have a choice. There are very few types in the 
package, but a lot of nested instances. So there is very little code needed 
to traverse these instances.  This might be more difficult in a different 
situation if many methods for wrapout() were required.

On Monday, October 10, 2016 at 12:20:50 AM UTC+2, lapeyre....@gmail.com 
wrote:
>
> I want to change show for Symbol, Rational, and Bool. Till now, I simply 
> overwrote the existing methods. This works great. I get what I want, even 
> in warn and error and string interpolation, etc. It works flawlessly on 
> v0.4, v0.5, and v0.6. But, this changes the behavior for everyone. So, I 
> want to get the same effect through different means that do not affect 
> other code. Any idea about how to do this ?
>
> One solution is to copy a large amount of  base code that uses print, 
> write, show, etc. renaming these functions. Other than changing 15 or 20 
> lines for Symbol, etc., the code is unchanged. This is works more or less, 
> but is obviously a fragile, bad solution.
>
> Another idea is to make a subtype of IO that wraps subtypes of IO. I am 
> allowed to write methods for show for this new type. This is turning out to 
> be complicated and unworkable.
>
> Another vague idea is to make a new mime type. Another is to copy IOStream 
> as another type, so that I only have to write methods for Symbol, Rational 
> and Bool again.
>
>  
>

Reply via email to