I think I understand what you are saying (not sure). A problem that arises is that if I call show or print on an object, then show or print may be called many times on fields and fields of fields, etc., including from within Base code before the call returns. I don't know how to tell the builtin julia code my preference for printing rationals. The only way I know to get a redefinition of show eg M.show to work in all situations, is to copy all the code that might be called. Maybe I'm missing something, but I can't see a way around this.
I'm not familiar with the idea of a fencing module. On Monday, October 10, 2016 at 11:30:18 PM UTC+2, Jeffrey Sarnoff wrote: > > You could wrap your redefinitions in a module M without exporting show > explicitly. > `using M` and accessing the your variation as `M.show` may give the > localization you want. > Should it not, then doing that within some outer working context, a > fencing module, may add enough flexibility. > > > On Monday, October 10, 2016 at 4:18:52 PM UTC-4, lapeyre....@gmail.com > wrote: >> >> 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. >>> >>> >>> >>
