Home > Archive > Smalltalk > April 2007 > can this be done? a message redirector
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
can this be done? a message redirector
|
|
| Emptist 2007-04-08, 8:05 am |
| When I change the name of some selectors recently, I think of a way
that I can't implement.
Say, I have a selector #oldSaying in class Something, which I have
copied to #newSaying, but want to let all previous sending of
#oldSaying shift in runtime automatically.
Can this be done:
newSaying
^true
oldSaying
"^true"
^self shouldShiftTo: #newSaying
the idea is when a third method, say, #sayings send #oldSaying to
someone, the system will update by itself, that is:
saying
something oldSaying ifTrue:[self doSomething]
will be changed to:
saying
something newSaying ifTrue:[self doSomething]
is this possible?
| |
| Cesar Rabak 2007-04-08, 7:06 pm |
| Emptist escreveu:
> When I change the name of some selectors recently, I think of a way
> that I can't implement.
> Say, I have a selector #oldSaying in class Something, which I have
> copied to #newSaying, but want to let all previous sending of
> #oldSaying shift in runtime automatically.
>
> Can this be done:
> newSaying
> ^true
>
> oldSaying
> "^true"
> ^self shouldShiftTo: #newSaying
>
> the idea is when a third method, say, #sayings send #oldSaying to
> someone, the system will update by itself, that is:
>
> saying
> something oldSaying ifTrue:[self doSomething]
>
> will be changed to:
> saying
> something newSaying ifTrue:[self doSomething]
>
> is this possible?
Why don't you use the Refactoring Browsing instead of creating the
'shouldShiftTo:' selector?
| |
| Niall Ross 2007-04-08, 7:06 pm |
| Dear Emptist,
> Say, I have a selector #oldSaying in class Something, which I have
> copied to #newSaying, but want to let all previous sending of
> #oldSaying shift in runtime automatically.
>
> Can this be done:
> newSaying
> ^true
>
> oldSaying
> "^true"
> ^self shouldShiftTo: #newSaying
>
> the idea is when a third method, say, #sayings send #oldSaying to
> someone, the system will update by itself, that is:
>
> saying
> something oldSaying ifTrue:[self doSomething]
>
> will be changed to:
> saying
> something newSaying ifTrue:[self doSomething]
>
> is this possible?
Rewriting on call is easily effected with method wrappers. (Read the paper
'Wrappers to the Rescue' from the www.refactory.com site if you are
unfamiliar with them.)
If your dialect is VW then you could look at the dynamic method renaming
code in the Custom Refactoring project's release for ideas.
(To get this, load the appropriate versions of the Tools-Refactoring Browser
and RefactoringBrowserTests bundles from the open repository. The latter
will prompt you to load the DynamicRenaming packages, and the
MethodWrapperBase and MethodWrapperExamples packages. I recommend loading
these from the repository, not from a VW release' parcels; load them first,
or explicitly load versions, if your settings load prereqs as parcels by
default.)
Yours faithfully
Niall Ross
| |
| Emptist 2007-04-08, 7:06 pm |
| On 4=D4=C29=C8=D5, =C9=CF=CE=E72=CA=B111=B7=D6, Cesar Rabak <csra...@yahoo.=
com.br> wrote:
> Emptist escreveu:
>
>
>
>
>
>
>
>
>
>
> Why don't you use the Refactoring Browsing instead of creating the
> 'shouldShiftTo:' selector?
The problem with RB is that in case oldSaying has been implemented in
several other classes which I don't want to change, RB can't make a
decision and will ask me to look at all related codes.
Use message sending will avoid this. I can decide which ones to
change.
Best Regards,
Jim G
| |
| Emptist 2007-04-08, 7:06 pm |
| On 4=D4=C29=C8=D5, =C9=CF=CE=E72=CA=B155=B7=D6, "Niall Ross" <n...@bigwig.n=
et> wrote:
> Dear Emptist,
>
>
>
>
>
>
>
>
>
>
> Rewriting on call is easily effected with method wrappers. (Read the pap=
er
> 'Wrappers to the Rescue' from thewww.refactory.comsite if you are
> unfamiliar with them.)
>
> If your dialect is VW then you could look at the dynamic method renaming
> code in the Custom Refactoring project's release for ideas.
>
> (To get this, load the appropriate versions of the Tools-Refactoring Brow=
ser
> and RefactoringBrowserTests bundles from the open repository. The latter
> will prompt you to load the DynamicRenaming packages, and the
> MethodWrapperBase and MethodWrapperExamples packages. I recommend loading
> these from the repository, not from a VW release' parcels; load them fir=
st,
> or explicitly load versions, if your settings load prereqs as parcels by
> default.)
>
> Yours faithfully
> Niall Ross
Thanks a lot for detailed info and I replied to your mail but the
reply is bounced back :)
I'll check them out.
Regards,
Jim G
| |
| jtzecher 2007-04-09, 7:07 pm |
| How about simply making a packaging rule that does it for you?
For example:
aPackagedImage replaceMethod: #oldSaying with: #newSaying
inClassNamed: #SayingExample.
The above line could be added to the #packagingRulesFor:
aPackagedImage method in any application in which SayingExample is
defined or extended. This wouldn't help you when you're working in
your smalltalk image but it would work appropriately in any packaged
image you create. This gets around your issue with changing classes
that you don't want to touch.
| |
| Emptist 2007-04-09, 7:07 pm |
| On 4=D4=C29=C8=D5, =CF=C2=CE=E79=CA=B129=B7=D6, "jteacher" <joel.zec...@ge.=
com> wrote:
> How about simply making a packaging rule that does it for you?
>
> For example:
>
> aPackagedImage replace Method: #old Saying with: #new Saying
> inClassNamed: #Saying Example.
>
> The above line could be added to the #packagingRulesFor:
> aPackagedImage method in any application in which Saying Example is
> defined or extended. This wouldn't help you when you're working in
> your smalltalk image but it would work appropriately in any packaged
> image you create. This gets around your issue with changing classes
> that you don't want to touch.
Yes, it's a way much simpler :) though not as  as changing things
in a running system but it's cleaner since it won't leave off dirty
codes containing abandoned selectors but not yet get called.
Now I'll go to find out where the rules live ;)
Any better mechanism? Perhaps, I could manage this shift when I
publish to Store?
Best Regards,
Jim G
| |
|
| Emptist wrote:
> When I change the name of some selectors recently, I think of a way
> that I can't implement.
> Say, I have a selector #oldSaying in class Something, which I have
> copied to #newSaying, but want to let all previous sending of
> #oldSaying shift in runtime automatically.
>
> Can this be done:
> newSaying
> ^true
>
> oldSaying
> "^true"
> ^self shouldShiftTo: #newSaying
I'm assuming #newSaying is also implemented by Something. So why not
just make #oldSaying invoke #newSaying, like this:
oldSaying
^self newSaying
Chris
| |
| Emptist 2007-04-09, 7:07 pm |
| On 4=D4=C29=C8=D5, =CF=C2=CE=E710=CA=B116=B7=D6, C L <b...@user.net> wrote:
> Emptist wrote:
>
>
>
> I'm assuming #newSaying is also implemented by Something. So why not
> just make #oldSaying invoke #newSaying, like this:
>
> oldSaying
> ^self newSaying
>
> Chris
Hi, Chris,
That's since I sometimes want to avoid some wrongly shared selector
names :)
After the shifting I'll search for senders of newSaying instead of
popular oldSaying :)
Regards,
Jim G
| |
| Niall Ross 2007-04-09, 7:07 pm |
| Dear Emptist,
> Thanks a lot for detailed info ... I'll check them out.
Hope it helps. Minor clarifications:
Browser
i.e. the latest whose version name begins
VW<your version number> CS<highest number> ...
(there are also many VW 7.5 pre-release versions in the Cincom OR; the
custom refactoring project has not yet publiched an integration of dynamic
renaming to these.)
[color=darkred]
loading[color=darkred]
first,[color=darkred]
[color=darkred]
> and I replied to your mail but the
> reply bounced back :)
You can remove the spam-trap to email me (but I read c.l.s regularly so a
posted reply will do unless it is very urgent or important).
If you have the RBDynamicRenaming... packages loaded and invoke standard
renaming from the RB on a polymorphic method then you will be warned that
the method has multiple implementors and offered 3 choices: to rename all,
to cancel, and to rename some. Choosing 'Rename Some...' opens the dynamic
renaming UI. You then run tests that exercise the calls you wish to rename
and/or select call sites by hand, whichever you prefer.
Yours faithfully
Niall Ross
| |
| Emptist 2007-04-10, 7:08 pm |
| On 4=D4=C210=C8=D5, =C9=CF=CE=E73=CA=B116=B7=D6, "Niall Ross" <n...@bigwig.=
net> wrote:
>
> If you have the RBDynamicRenaming... packages loaded and invoke standard
> renaming from the RB on a polymorphic method then you will be warned that
> the method has multiple implementors and offered 3 choices: to rename al=
l,
> to cancel, and to rename some. Choosing 'Rename Some...' opens the dynam=
ic
> renaming UI. You then run tests that exercise the calls you wish to rena=
me
> and/or select call sites by hand, whichever you prefer.
>
> Yours faithfully
> Niall Ross
Thanks Niall, it's almost a clear instruction now. I posted a reply
this noon but it has not shown up.
Regards,
Jim G
|
|
|
|
|