Bill
You wrote in message news:acgmq4$o01na$
[hidden email]...
>
> If anything, saying that the RB is "built-in" to D5 is an understatement -
> it's very smoothly integrated. Nice work!
Thank you.
> ...
> Would it be reasonable to put an error trap in a formatter's #format: and
> fall back on RBFormatter if something went wrong? Put another way, is
> #format: the "entry point" to a formatter?
Yes, I believe so.
>...Would you recommend subclassing
> RBFormatter (it seems like overriding some of the #format* methods might
> suffice), or starting over with a sybling of it?
Off the top of my head I don't really know, sorry. John Brant is probably
the best person to ask - he is a busy chap, but occassionally contributes to
this news group.
I have successfully subclassed RBFormatter to write a SmalltalkToCPP class
that I used to emit C++ CPPUnit classes converted from SUnit TestCases (for
a very limited Smalltalk "style"), but from what I understand that may not
be the best place to start when writing a formatter more to one's own taste.
From what John tells me the configurable formatter (RBConfigurableFormatter)
should be a lot easier to understand and (therefore one assumes) subclass,
so I would recommend starting there.
>
> Would it be enough to add a new formatter to the
> 'System-Compiler-Formatters' category, or is more required before using
it?
That will be sufficient to have it appear in the User Preferences for the
development system, yes.
> Are there any other questions I should be asking?
"Well Grasshopper...." :-)
>
> Just out of curiosity, can the RB refactor itself? =:0
Oh yes, though presumably one might be able to contrive some examples that
will break it.
Regards
Blair