Le 23/1/16 03:38, Ben Coman a écrit :
Sounds interesting, but my head hurts trying to think about this more
deeply :)
so I'm going to keep at a superficial level on this for now.
So just thinking out loud...
If you have
mother1 := foo:(bar:zork:fork)
mother2 := foo:bar:(zork:bork:)
I'm not sure that this is allows in the same class. We should check that
in Python or ruby.
When you search for senders of #foo:bar: what do you get back and how
to display it?
We should display every caller.
Maybe a two level tree list with the option combinations appearing at
the top level and each of their senders at the second level, hiding
any top level items that don't have children.
foo:bar:
foo:bar:zork:
foo:bar:fork:
foor:bar:bork
foo:bar:zork:fork:
foo:bar:fork:zork:
foo:bar:zork:bork:
foo:bar:bork:zork:
Actually, full any order combination probably becomes unwieldly.
Maybe there should be a constraint that optional arguments can be
skipped but when used must be used in sequence.
cheers -ben
btw, how do you mean relationship?
I mean knowing the mother from the children
Do you mean using a Slots
mechanism like the relationship demo in the Flexible Object layouts
paper?
no
https://hal.inria.fr/hal-00641716/file/Verw11b-OOSPLA11-FlexibleObjectLayouts.pdf
On Sat, Jan 23, 2016 at 3:29 AM, stepharo <[email protected]> wrote:
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.
