|Anonymous | Login||01-21-2020 15:00 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ View Advanced ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0006457||[Squeak] System||major||N/A||05-03-07 06:21||05-06-07 05:37|
|Summary||0006457: [RFI] Need a utility to check on super unimplemented calls.|
You can ask for unimplemented calls and get a list of messages that are sent but not implemented.
But there is also a class of methods that are implemented but which are not implement when called by super.
I would like to see have a way to find all the methods sent to super which are not implemented.
There is at least one bug in 3dot9 that falls in this catagory. A way to find others or prove they don't exist is needed.
A tip of the hat to sharp eyed Sudheendra Hangal for finding the first case.
See my reply on the beginners list:
[Newbies] Re: PolygonMorph intersection
SuperSendFinder.st [^] (847 bytes) 05-03-07 12:16
CompiledMethod-superSends.st [^] (457 bytes) 05-03-07 12:16
SystemNavigation-allSuperSendByClass.st [^] (600 bytes) 05-03-07 12:17
SuperCallsProbe-wiz.1.cs [^] (2,896 bytes) 05-06-07 05:25
WizExample2.gif [^] (7,239 bytes) 05-06-07 05:29
(0010646 - 360 - 420 - 420 - 420 - 420 - 420)
edited on: 05-03-07 12:18
I attached a little helper class that collect super sends based on scanning CompiledMethod (with an InstructionClient subclass).
This is unfinished:
- no check of unimplemented is down
- no user interface is provided
I'am not really sure what to do when method #a sends super #b...
Also note that we could use same kind of tests for calls to self
(0010652 - 677 - 773 - 773 - 773 - 773 - 773)
Thanks for the help.
What I am hoping to do is to better discern when a call is unimplemented.
The related bug that inpired this report reminded me that just because a method exists somewhere in the system does not mean in implements a particular call.
The super calls are a good case to track down because that implies there need to be at least two method implementations.
And for self calls then there would need to be at least one call in the class it is called from or above.
So there should be some way to probe for this and what we can track we can fix.
I'll look at what you've supplied.
Yours in curiosity and service, --Jerome Peace
(0010653 - 461 - 527 - 527 - 527 - 527 - 527)
Easy trivial case:
if A>>#a sends super a, then just need to check if #a is implemented in superclasses of A
But if A>>#a sends super b, what does it mean?
if #b is not implemented in A, but is in A superclass and in A superclass superclass,
then which super b is called?
If ever it is A superclass superclass>>#b, and you remove one of the #b implementation, I guess this is an unimplemented call case...
I do not know, and did not took time to test.
(0010654 - 809 - 929 - 929 - 929 - 929 - 929)
Remember, partial progress counts.
If we can catch the *a* cases that will help.
I also agree that the *b* cases are problematic. You would have to test a particular implementation of smalltalk to find out how it behaved and even then it probably wouldn't be a stable behavior across platforms or time.
So my solution would be to warn of every case of super b calls. They would be very risky coding.
Super calls in general are bad form because they pin down the heirarchy.
The one place you would want them is in the *a* type case where every subclass added its superclasses behavior to a.
e.g. initialize and menu building.
Most other uses are good targets for repair and refactoring so all we need do is find and report them.
Partial progress counts.
(0010667 - 727 - 793 - 793 - 793 - 793 - 793)
edited on: 05-06-07 05:40
SuperCallsProbe-wiz.1.cs has an experiment with three hierarcical classes and calls to super from different levels of the heirarchy.
The gif is the result from running the example2 and putting it in an explorer.
The interesting thing I found out is that super call is determined at compile time and does not adjust to bind to the super class of the instance calling it which is slightly opposite of what you might expect because calls to self do it the other way.
My current thinking is that this is probably for the best. And it is another good reason to use super calls sparingly.
I don't think I covered all the possible cases but I did cover some unusual ones. Feel free to try other variations.
|05-03-07 06:21||wiz||New Issue|
|05-03-07 12:15||nicolas cellier||Note Added: 0010646|
|05-03-07 12:16||nicolas cellier||File Added: SuperSendFinder.st|
|05-03-07 12:16||nicolas cellier||File Added: CompiledMethod-superSends.st|
|05-03-07 12:17||nicolas cellier||File Added: SystemNavigation-allSuperSendByClass.st|
|05-03-07 12:18||nicolas cellier||Note Edited: 0010646|
|05-03-07 21:30||wiz||Relationship added||related to 0006461|
|05-03-07 22:38||wiz||Note Added: 0010652|
|05-03-07 22:53||nicolas cellier||Note Added: 0010653|
|05-03-07 23:21||wiz||Note Added: 0010654|
|05-06-07 05:25||wiz||File Added: SuperCallsProbe-wiz.1.cs|
|05-06-07 05:29||wiz||File Added: WizExample2.gif|
|05-06-07 05:37||wiz||Note Added: 0010667|
|05-06-07 05:40||wiz||Note Edited: 0010667|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
69 total queries executed.|
37 unique queries executed.