RB formatters

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

RB formatters

Bill Schwab-2
Andy and Blair,

If anything, saying that the RB is "built-in" to D5 is an understatement -
it's very smoothly integrated.  Nice work!

Of course, we users are never satisfied<g>, and I've been trying to make the
RB's output look a little more the way I format my code.  One simple hack
(removing the space between keyword selectors and arguments) helped a lot.
Block formatting might be next; again something simple like moving the [ in
front of the cr would probably get a lot closer to my formatting.  The
C-style blocks of the configurable formatter might be a good starting point
for my tweaks, but, don't quite do what I want as-is.

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?  Would you recommend subclassing
RBFormatter (it seems like overriding some of the #format* methods might
suffice), or starting over with a sybling of it?

Would it be enough to add a new formatter to the
'System-Compiler-Formatters' category, or is more required before using it?
Are there any other questions I should be asking?

Just out of curiosity, can the RB refactor itself?  =:0

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: RB formatters

Blair McGlashan
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