RB Enhancements that are low hanging fruit

153 views
Skip to first unread message

jtu...@objektfabrik.de

unread,
May 13, 2013, 5:27:20 AM5/13/13
to va-sma...@googlegroups.com
HI,

I am in the process of refactoring lots of code and found a few tiny enhancements that would make me more productive with (presumably) little effort:

1. When I rename a method and get a prompter, add a title to the prompter saying "rename method xxx to?" instead of "Refactory"
2. Set the input focus onto the input field for the new method name instead of the OK button, preselect the contents of the input field so that I can start typing right away
3. Make the OK Button the default button

The same is true for the prompter of teh extract methode refactoring and probably some others.

Joachim



Thomas Koschate

unread,
May 13, 2013, 6:02:55 AM5/13/13
to va-sma...@googlegroups.com
On Monday, May 13, 2013 5:27:20 AM UTC-4, jtu...@objektfabrik.de wrote:
 
I am in the process of refactoring lots of code and found a few tiny enhancements that would make me more productive with (presumably) little effort:

Well, if we're going there,I've got another one.  It would be really nice if refactorings would stop throwing in extraneous parentheses!

Tom

jtu...@objektfabrik.de

unread,
May 13, 2013, 7:58:20 AM5/13/13
to va-sma...@googlegroups.com
Hi Tom,

I rarely see extraneous parentheses. Do you mix RB with VA Code Assist?

As I said, the improvements I mentioned in my first post were low hanging fruit, meaning they don't require going into RB internals at all.

There's a long list here in my drawer about RB improvements. Some even made me tinker around a little, but I finally put them aside because there were other things to do (and things started to become more complicated than it seemed to be at the start).

Just a few examples:

Why Does RB ask me which Accossor(s) to create if I selected one or more instance var names?
Why does RB always reformat my source code - and why is the way it formats different than QA code formatter? Same goes for remove.
The menu items should be consolidated and cleaned up. You often end up searching for extract method and extract to temporary because they are not in the place where you expect them.

Joachim

Thomas Koschate

unread,
May 13, 2013, 6:08:42 PM5/13/13
to va-sma...@googlegroups.com
Probably the most common refactoring I do is Extract Method. This causes the extra parentheses, not to mention the annoying code format differences between RB and QA formatters that I don't even want to get started on.

Tom

jtu...@objektfabrik.de

unread,
May 14, 2013, 2:19:28 AM5/14/13
to va-sma...@googlegroups.com
Tom,

okay, I see. it seems I never got upset about the result of extract method... but i hate how extract method treats comments in the extracted code.

But the code formatting in RB is evil. Not only does it reformat differently than QA, it also removes all my blank lines. I do place blank lines to improve readabilty (at least I think it improves readability) very much. RB simply wipes them out and I sometimes have to bite on my tongue not to do physical harm to my computer...

I think there should be an option for RB not to format at all, or a possibility to plug QA formatter into rb. or better both.

But this is another category than the simple enhancements I mwntioned initially. Those could be integrated and tested in very little time and have some impact on developers' workflow.

Joachim

Joachim

Thomas Koschate

unread,
May 14, 2013, 7:21:40 AM5/14/13
to va-sma...@googlegroups.com
I'm away from my Smalltalk environment for the week, but I seem to recall some ability to change the RB's formatter behavior, but I could never get it to match the QA formatter. You can't get away from changes to the formatted code because the RB does its work on an internalized version of the method and then spits out a refactored lexically equivalent version. However, a pass through the QA formatter should be possible. I've tried, but not very hard.

I agree -there's other low-hanging fruit, but we don't seem to be making enough noise about it.

Tom

jtu...@objektfabrik.de

unread,
May 14, 2013, 10:02:03 AM5/14/13
to va-sma...@googlegroups.com
At least the two of us try now ;-) 
Enjoy your absence from Smalltalk ;-)

Joachim

Joachim Tuchel

unread,
May 20, 2020, 5:42:38 AM5/20/20
to VA Smalltalk
Coming back to this, because Pharo people also don't like the fact that RB reformats code, or at least does so in a different way than the platform's formatters do (in our case QA Code formatter, for example).


So I guess it would be great if there was some kind of plugin mechanism in RB that invokes some "native" code formatter instead of introducing its own strange one...

It's a bit annoying that a method rename potentially reformats a couple hundred methods in the blink of an eye and leaves the cleaning to the user....

Richard Sargent

unread,
May 20, 2020, 12:37:04 PM5/20/20
to VA Smalltalk
On Wednesday, May 20, 2020 at 2:42:38 AM UTC-7, Joachim Tuchel wrote:
Coming back to this, because Pharo people also don't like the fact that RB reformats code, or at least does so in a different way than the platform's formatters do (in our case QA Code formatter, for example).


So I guess it would be great if there was some kind of plugin mechanism in RB that invokes some "native" code formatter instead of introducing its own strange one...

I know at least one version of the RB had a pluggable formatter. I don't know if that's the case with the current code base.

Richard Sargent

unread,
May 20, 2020, 12:56:12 PM5/20/20
to VA Smalltalk
I have exported an application I created quite a while ago to tweak the default RBFormatter behaviour. As of VA 6.0.2, it worked. It probably needs some renewal to work with the current versions. It's attached, in a zip file.

The two big changes are:
1) to force #ifTrue:ifFalse: to have their expressions on separate lines from the receiver expression and each other.
2) to force and: [ ...and: [ ...and: [.... to go on separate lines with the and: keyword lined up vertically. It isn't perfect, but 90% was better than nothing.

It is free for anyone to do anything they like with it. Public Domain. Have fun.
FormattingApp.zip

Joachim Tuchel

unread,
May 22, 2020, 4:09:34 AM5/22/20
to VA Smalltalk
Richard,


this is interesting. Stef also mentioned this on the pharo mailing list, I wasn't aware of this.
Do you happen to know where to llok for this hook? I'd love to experiment with uing the QA Code Formatter as the default formatter for RB...

Joachim

Mariano Martinez Peck

unread,
May 22, 2020, 9:45:22 AM5/22/20
to VA Smalltalk
On Fri, May 22, 2020 at 5:09 AM Joachim Tuchel <jtu...@objektfabrik.de> wrote:
Richard,


this is interesting. Stef also mentioned this on the pharo mailing list, I wasn't aware of this.
Do you happen to know where to llok for this hook? I'd love to experiment with uing the QA Code Formatter as the default formatter for RB...


+ That would be good. At least as an option.

 
--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Seth Berman

unread,
May 22, 2020, 10:21:29 AM5/22/20
to VA Smalltalk
Hi,

I'm less familiar with the code behind the RefatoringBrowser...but I see
RBProgramNode>>#formattedCode

From here, it looks like it would call 'FormatterClass' class var which you might inject the class CfFormatter into.

As an experiment, you could then implement CfFormatter>>#format:

Ideally, from this method you would return something like '^self formatText: aNode source class: methodClass width: 100'
except that I don't see where I have access to the methodClass....and I'm guessing its simply not available by design since it seems to be a sort of context-free formatter.

But like I said, I'm not familiar enough with the code, so what I showed just might be a place where you could start looking.

- Seth


On Friday, May 22, 2020 at 9:45:22 AM UTC-4, Mariano Martinez Peck wrote:


On Fri, May 22, 2020 at 5:09 AM Joachim Tuchel <jtu...@objektfabrik.de> wrote:
Richard,


this is interesting. Stef also mentioned this on the pharo mailing list, I wasn't aware of this.
Do you happen to know where to llok for this hook? I'd love to experiment with uing the QA Code Formatter as the default formatter for RB...


+ That would be good. At least as an option.

 
--
Mariano Martinez Peck
Software Engineer, Instantiations Inc.

Richard Sargent

unread,
May 22, 2020, 11:22:12 AM5/22/20
to VA Smalltalk


On Fri, May 22, 2020, 01:09 Joachim Tuchel <jtu...@objektfabrik.de> wrote:
Richard,


this is interesting. Stef also mentioned this on the pharo mailing list, I wasn't aware of this.
Do you happen to know where to llok for this hook? I'd love to experiment with uing the QA Code Formatter as the default formatter for RB...

The exported app that I shared shows the way.

I don't know anything about the QA Code Formatter. Unless it provides the same API as the RB Formatter, I don't see how it could be used by the RB tools.

--
You received this message because you are subscribed to a topic in the Google Groups "VA Smalltalk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/va-smalltalk/C59IoRlsiRs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/81bd99c7-e4ad-4547-bdef-eff977444032%40googlegroups.com.

Joachim Tuchel

unread,
May 22, 2020, 2:50:25 PM5/22/20
to VA Smalltalk
Hi Richard.

I am slowly coming to this conclusion as well. RBFormatter formats RBProgramNodes. This can be Methods, but also smaller artefacts like Assignments, Blocks, Message sends  etc. CfFormatter formats methods and "bigger" artefacts like Applications, etc.
At first sight, it seems like RBProgramNodes somewhat map to EsParseNodes that are used in CfFormatter. If I understand correctly, ESParseNodes end up writing themselves onto a Stream in #formatOn: while RBFormatter implements he formatting for each kind of node in its #format*: protocol.

So it seems what needs to be done is convert the RBNodes (after refactoring) to EsParseNodes and have those do their output. Seems like Richard's approach of subclassing RBFormatter with a Class that does this converson and implements the API of RBFormatter and delegates the actual formatting to the created EsPerseNodes is the way to go.

Not actually a trivial thing, and not what I'd call a hook ;-) I'll probably play around a little with this idea and see if I get anywhere...


Joachim
To unsubscribe from this group and all its topics, send an email to va-sma...@googlegroups.com.

Richard Sargent

unread,
May 22, 2020, 3:51:43 PM5/22/20
to VA Smalltalk
On Fri, May 22, 2020 at 11:50 AM Joachim Tuchel <jtu...@objektfabrik.de> wrote:
Hi Richard.

I am slowly coming to this conclusion as well. RBFormatter formats RBProgramNodes. This can be Methods, but also smaller artefacts like Assignments, Blocks, Message sends  etc. CfFormatter formats methods and "bigger" artefacts like Applications, etc.
At first sight, it seems like RBProgramNodes somewhat map to EsParseNodes that are used in CfFormatter. If I understand correctly, ESParseNodes end up writing themselves onto a Stream in #formatOn: while RBFormatter implements he formatting for each kind of node in its #format*: protocol.

So it seems what needs to be done is convert the RBNodes (after refactoring) to EsParseNodes and have those do their output. Seems like Richard's approach of subclassing RBFormatter with a Class that does this converson and implements the API of RBFormatter and delegates the actual formatting to the created EsPerseNodes is the way to go.

I guess one of the things that hasn't been discussed is what formatting differences you desire compared to the default RB formatting. Adapting a different formatting strategy to RB might be more work than writing the RB formatter to do it. I'm not saying it would be, as I don't know what your goals are.

I am always wary of "This is the solution I want to the (unarticulated) problem I have" statement of requirements.


Not actually a trivial thing, and not what I'd call a hook ;-) I'll probably play around a little with this idea and see if I get anywhere...

Definitely not trivial. Hence my thought that staying in the RB realm might be easier. *might*

To unsubscribe from this group and all its topics, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/46c1d049-df80-4cbe-a9fe-cf457cb9a850%40googlegroups.com.

Joachim Tuchel

unread,
May 25, 2020, 1:25:15 AM5/25/20
to VA Smalltalk
Hi Richard,

havng looked into this RB reformatting stuff a little, I tend to agree. Maybe the way to go is tame RB's reformatting the way you did and reuse that in order to replace QA Code Formatter. All that's needed is a menu item and keyboard shortcut in the browsers once the RB reformatter does a better job...

Joachim

Steven LaFavor

unread,
Jun 2, 2020, 6:59:23 PM6/2/20
to VA Smalltalk

I had posted something last August here in the forums about overriding the sourceString method of CompiledMethod to use the Envy QA formatter to allow people to see the code formatted the way they like without triggering a save every time it gets reformatted.  Don't know if it is useful to anyone, but here's the link to the thread.....


*Steve* 
Reply all
Reply to author
Forward
0 new messages