Why can't I refactor unless I save?

Is there a technical reason why you can't refactor unless you save your
method?

I know that the parser happily gives nodes when things aren't saved -
so I don't understand why it can't let me refactor (especially if there
are no errors in the code - again something that is available) and just
do the save for me.

I am interested in this (and it can be problematic), becase if you save
and there are any warnings left in your code (e.g. unused variables
etc) then your cursor/selection will jump to the first warning (which
is a good feature - but not if you have hilited something to refactor).
Thus you then have to releselect the refactoring again.

Tim

Tim,

> Is there a technical reason why you can't refactor unless you save your
> method?

I suspect the answer will be that it runs against the idea of
refactoring, which is to preserve behavior.  Making such transformations
on something that is not part of the current behavior is inconsistent
with the mission - I think :)

Of course, Dolphin add package scope to refactoring, which is in direct
violation of the definition of refactoring, and a damn useful violation
if some code suffers from (e.g.) an overly generic selector.  Would your
problem fit into a similar category: a useful transformation that isn't
necessarily behavior-preserving?

Have a good one,

Bill


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

"TimM" <[hidden email]> wrote in message
news:[hidden email]...
> Is there a technical reason why you can't refactor unless you save your
> method?
>

The basic reason is that many of the refactorings also affect other code
artefacts, and so it would not be preserving behaviour to apply a
refactoring across saved methods/class definitions that are currently in use
as well as unsaved code. I suppose this is one of the differences with
coding in a live environment, rather than a set of unsaved files. Of course
it would be possible to create a model of the system that represented the
complete unsaved state, including any pending refactorings, so that when you
saved the method it also applied all the refactoring changes. The RB's
existing model classes could be used to implement this I think. However I
suspect it might turn well turn out to be more complex to use that it is
worth - after all you'd lose much of the "immediacy" of the normal way of
working in Smalltalk, plus you'd have to deal with conflicts that might
arise from multiple editing sessions. It fails to pass the complexity filter
for me.

On the other hand there are some refactorings (extract temporary springs to
mind) that have only local effect, or which are typically benign (e.g.
adding an instance variable) and so obviously these could be performed quite
safely in an unsaved method. I had hoped to do something about this in X6,
but again it didn't make the cut. Actually that's not quite true, as some of
the auto-correct operations are refactorings, but it would be worth formally
recording as an enhancement request I think.

Regards

Blair

TimM wrote:

> Is there a technical reason why you can't refactor unless you save your
> method?

But, but, but...  How can you Refactor unless you have a Test that Passes ?
And how can you have a Test that Passes before you have saved your method ?

(No, please don't get excited -- I'm only taking the piss a little ;-)

    -- chris