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.
