Ben We were thinking also about reflection. So may be we should introduce a relationship between the method and its actual implementation. Imagine that mother := foo:(bar:zork:) mother children foo:bar: foo:bar:zork: then senders (foo:bar:) => sender (motherOf(foo:bar:)) where motherOf is a back pointer from the expanded method into its mother But it means that method using foo:bar: should somehow "mention" that they will use motherOf (foo:bar:). Le 22/1/16 01:41, Ben Coman a écrit :
I don't have any use cases right now, but I'll keep my eyes open. But an example (that is maybe too basic to mess with) is the #at:ifAbsent: pattern. For example, the following would be "deleted"
Dictionary>>.at: key ^ self at: key ifAbsent: [self errorKeyNotFound: key]
and you would only have....
Dictionary>>at: key ifAbsent: aBlock <optional: ifAbsent default: [ self errorKeyNotFound: key]>
The big in-Image example would be...
TClass>> subclass: aName uses: aTraitCompositionOrArray instanceVariableNames: someInstanceVariableNames classVariableNames: someClassVariableNames poolDictionaries: someSharedPoolNames package: aCategory <optional: uses default: {}> <optional: instanceVariableNames default: ''> <optional: classVariableNames default: ''> <optional: poolDictionaries default:''> <optional: package 'Unclassified'>
Now I wonder about senders & implementers searchability, and if "virtual" methods are generated in all combinations of optional parameters and show up in the system browser list, but show the "main" method as their source.