Kernel currently depends on Graphics because the MethodFinder references Color and Point.
I would like to remove this dependency, but to do while while preserving MethodFinder's near-magical utility, it looks like we'd need some kind of pluggable extension thing.
In other words, MethodFinder would provide some kind of API such that Graphics could say "you know MethodFinder, you ought to try these classes - Color and Point - and these methods - #@ and so on - when you run."
MethodFinder >> #testRandom, #testTuple and #verify could then walk these per-package collections of interesting things when it does its thing.
I would _really really_ appreciate someone (other than me) applying some grey matter to this problem.
frank
Couldn't those methods referencing Color and Point simply be moved to Graphics?
On Wed, Jul 24, 2013 at 7:14 AM, Frank Shearar frank.shearar@gmail.com wrote:
Kernel currently depends on Graphics because the MethodFinder references Color and Point.
I would like to remove this dependency, but to do while while preserving MethodFinder's near-magical utility, it looks like we'd need some kind of pluggable extension thing.
In other words, MethodFinder would provide some kind of API such that Graphics could say "you know MethodFinder, you ought to try these classes - Color and Point - and these methods - #@ and so on - when you run."
MethodFinder >> #testRandom, #testTuple and #verify could then walk these per-package collections of interesting things when it does its thing.
I would _really really_ appreciate someone (other than me) applying some grey matter to this problem.
frank
Yes, but that doesn't solve the actual problem: MethodFinder's really useful, but whatever package it lives in must of necessity reference every package that contains classes useful in finding methods.
So we could move MethodFinder out of Kernel. If we moved it to System-Support, System would depend slightly more on Graphics than it did before, but that's fine. I _still_ think MethodFinder would be much improved by being made pluggable. But moving MethodFinder would satisfy my initial desire and break the Kernel -> Graphics dependency!
frank
On 25 July 2013 16:46, Chris Muller asqueaker@gmail.com wrote:
Couldn't those methods referencing Color and Point simply be moved to Graphics?
On Wed, Jul 24, 2013 at 7:14 AM, Frank Shearar frank.shearar@gmail.com wrote:
Kernel currently depends on Graphics because the MethodFinder references Color and Point.
I would like to remove this dependency, but to do while while preserving MethodFinder's near-magical utility, it looks like we'd need some kind of pluggable extension thing.
In other words, MethodFinder would provide some kind of API such that Graphics could say "you know MethodFinder, you ought to try these classes - Color and Point - and these methods - #@ and so on - when you run."
MethodFinder >> #testRandom, #testTuple and #verify could then walk these per-package collections of interesting things when it does its thing.
I would _really really_ appreciate someone (other than me) applying some grey matter to this problem.
frank
Yes, but that doesn't solve the actual problem: MethodFinder's really useful, but whatever package it lives in must of necessity reference every package that contains classes useful in finding methods.
So we could move MethodFinder out of Kernel. If we moved it to System-Support, System would depend slightly more on Graphics than it did before, but that's fine. I _still_ think MethodFinder would be much improved by being made pluggable. But moving MethodFinder would satisfy my initial desire and break the Kernel -> Graphics dependency!
Why wouldn't MethodFinder be part of Tools?
On 25 July 2013 19:22, Chris Muller ma.chris.m@gmail.com wrote:
Yes, but that doesn't solve the actual problem: MethodFinder's really useful, but whatever package it lives in must of necessity reference every package that contains classes useful in finding methods.
So we could move MethodFinder out of Kernel. If we moved it to System-Support, System would depend slightly more on Graphics than it did before, but that's fine. I _still_ think MethodFinder would be much improved by being made pluggable. But moving MethodFinder would satisfy my initial desire and break the Kernel -> Graphics dependency!
Why wouldn't MethodFinder be part of Tools?
Indeed, why not? I think that's a good idea!
frank
On Jul 25, 2013, at 11:22 AM, Chris Muller ma.chris.m@gmail.com wrote:
Yes, but that doesn't solve the actual problem: MethodFinder's really useful, but whatever package it lives in must of necessity reference every package that contains classes useful in finding methods.
So we could move MethodFinder out of Kernel. If we moved it to System-Support, System would depend slightly more on Graphics than it did before, but that's fine. I _still_ think MethodFinder would be much improved by being made pluggable. But moving MethodFinder would satisfy my initial desire and break the Kernel -> Graphics dependency!
Why wouldn't MethodFinder be part of Tools?
+1
squeak-dev@lists.squeakfoundation.org