Mantis Bugtracker

Viewing Issue Advanced Details Jump to Notes ] View Simple ] 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
Reporter wiz View Status public  
Assigned To
Priority high Resolution open Platform
Status new   OS
Projection none   OS Version
ETA none Fixed in Version Product Version
  Product Build
Summary 0006457: [RFI] Need a utility to check on super unimplemented calls.
Description 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.

Steps To Reproduce
Additional Information 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

Attached Files [^] (847 bytes) 05-03-07 12:16 [^] (457 bytes) 05-03-07 12:16 [^] (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

- Relationships
related to 0006461closed  PolygonMorph intersects method does not work 

- Notes
(0010646 - 360 - 420 - 420 - 420 - 420 - 420)
nicolas cellier
05-03-07 12:15
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)
05-03-07 22:38

Hi Nicolas,

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)
nicolas cellier
05-03-07 22:53

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)
05-03-07 23:21

Hi Nicolas,

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.

Cheers --Jer
(0010667 - 727 - 793 - 793 - 793 - 793 - 793)
05-06-07 05:37
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.

Cheers -Jer


- Issue History
Date Modified Username Field Change
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:
05-03-07 12:16 nicolas cellier File Added:
05-03-07 12:17 nicolas cellier File Added:
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.
Powered by Mantis Bugtracker