[Pharo-project] Scriptable CompileMethod interface
Today on the train I was a bit bored on what I can do with CompiledMethods⦠It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methods⦠(Object >> #at:) overrides "return all direct overrides of this method" (Bag >> #at:) super "return the method I override" (Bag >> #at:) superChain "return all implementations in superclasses" (Object >> #name) senders (Object >> #name) implementors instead of doing something like SystemNavigation default allCallsOn: #name "(BTW I would prefer allSendersOf: #name)" What do you think? Does this make sense or not? cami
On Sep 1, 2011, at 12:35 AM, Camillo Bruni wrote:
Today on the train I was a bit bored on what I can do with CompiledMethodsâ¦
It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methodsâ¦
(Object >> #at:) overrides "return all direct overrides of this method" Look in Nautilus, I have wrote an extension for that
(Bag >> #at:) super "return the method I override" Bag super lookupSelector: #at: ?
(Bag >> #at:) superChain "return all implementations in superclasses" +1
(Object >> #name) senders +1
(Object >> #name) implementors +1
instead of doing something like
SystemNavigation default allCallsOn: #name "(BTW I would prefer allSendersOf: #name)"
What do you think? Does this make sense or not?
cami
Ben ;)
2011/9/1 Camillo Bruni <camillo.bruni@inria.fr>:
Today on the train I was a bit bored on what I can do with CompiledMethodsâ¦
It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methodsâ¦
(Object >> #at:) overrides    "return all direct overrides of this method" (Bag >> #at:) super       "return the method I override" (Bag >> #at:) superChain     "return all implementations in superclasses" (Object >> #name) senders (Object >> #name) implementors
instead of doing something like
SystemNavigation default allCallsOn: #name  "(BTW I would prefer allSendersOf: #name)"
What do you think? Does this make sense or not?
cami
I'm not convinced. (Object >> #name) senders 1) works only if you know a class that implements #name 2) technically it won't return the senders of (Object >> #name) but the senders of (AnyOtherClass >> #name) (Object >> #name) implementors 1) same as above, you must first know an implementor... (Bag >> #at:) super /superChain is a bit better, but there is again no garanty that Bag implements at:, still I might want to see all implementors in superclasses. Nicolas
On 2011-09-01, at 00:54, Nicolas Cellier wrote:
2011/9/1 Camillo Bruni <camillo.bruni@inria.fr>:
Today on the train I was a bit bored on what I can do with CompiledMethodsâ¦
It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methodsâ¦
(Object >> #at:) overrides "return all direct overrides of this method" (Bag >> #at:) super "return the method I override" (Bag >> #at:) superChain "return all implementations in superclasses" (Object >> #name) senders (Object >> #name) implementors
instead of doing something like
SystemNavigation default allCallsOn: #name "(BTW I would prefer allSendersOf: #name)"
What do you think? Does this make sense or not?
cami
I'm not convinced. (Object >> #name) senders 1) works only if you know a class that implements #name 2) technically it won't return the senders of (Object >> #name) but the senders of (AnyOtherClass >> #name)
Yes this is absolutely correct. But I think might have not been clear about my intentions. I do not want to replace SystemNavigation default * calls. But make sure that once you actually have a CompiledMethod you can browse from there on. Thats what the (Object >> #name) actually should mean, I should have chosen some better example like (String >> #printOn:) or so.
(Object >> #name) implementors 1) same as above, you must first know an implementorâ¦
Again, you start from an existing implementation (Object >> #name) just happens to be a random example..
(Bag >> #at:) super /superChain is a bit better, but there is again no garanty that Bag implements at:, still I might want to see all implementors in superclasses.
Nope, (Bag >> #at:) will fail if the method doesn't exist.
Nicolas
I guess what you want meant is the same navigation interface on Symbol: #name implementors #foo:bar: senders #at: superChain: Bag "definitely needs another name :)" #at: implementorsAbove: Bag "might be betterâ¦" cami
2011/9/1 Camillo Bruni <camillo.bruni@inria.fr>:
On 2011-09-01, at 00:54, Nicolas Cellier wrote:
2011/9/1 Camillo Bruni <camillo.bruni@inria.fr>:
Today on the train I was a bit bored on what I can do with CompiledMethodsâ¦
It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methodsâ¦
(Object >> #at:) overrides    "return all direct overrides of this method" (Bag >> #at:) super       "return the method I override" (Bag >> #at:) superChain     "return all implementations in superclasses" (Object >> #name) senders (Object >> #name) implementors
instead of doing something like
SystemNavigation default allCallsOn: #name  "(BTW I would prefer allSendersOf: #name)"
What do you think? Does this make sense or not?
cami
I'm not convinced. (Object >> #name) senders 1) works only if you know a class that implements #name 2) technically it won't return the senders of (Object >> #name) but the senders of (AnyOtherClass >> #name)
Yes this is absolutely correct. But I think might have not been clear about my intentions. I do not want to replace SystemNavigation default * calls. But make sure that once you actually have a CompiledMethod you can browse from there on. Thats what the (Object >> #name) actually should mean, I should have chosen some better example like (String >> #printOn:) or so.
(Object >> #name) implementors 1) same as above, you must first know an implementorâ¦
Again, you start from an existing implementation (Object >> #name) just happens to be a random example..
(Bag >> #at:) super /superChain is a bit better, but there is again no garanty that Bag implements at:, still I might want to see all implementors in superclasses.
Nope, (Bag >> #at:) will fail if the method doesn't exist.
Nicolas
I guess what you want meant is the same navigation interface on Symbol:
#name implementors #foo:bar: senders #at: superChain: Bag      "definitely needs another name :)" #at: implementorsAbove: Bag  "might be betterâ¦"
cami
Yes, but this will reopen the Symbol/Selector thread ;) Nicolas
Well if you are browsing from a console like interface, then yes, these might be useful. Let me make some funky suggestions with pure sugar, just to let you type less in a console: If you want sub implementors, then use Bag / for telling to look under Bag hierarchy (Bag />> #at:) For reversing the direction and look super, it can be nothing else but a backslash (Bag \>> #at:) It also works with super super (Bag \\>> #at:) Requesting all the super implementors requires a wild card of course (Bag \*>> #at:) If you want both, it could have been with /\>> but it is much simpler with a single wild card (Bag *>> #at:) Just reverse the >> and... (Bag << #at:) could return the senders of #at: within Bag. If you don't like it, I have an excuse: it's late here ;) Bye Nicolas 2011/9/1 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2011/9/1 Camillo Bruni <camillo.bruni@inria.fr>:
On 2011-09-01, at 00:54, Nicolas Cellier wrote:
2011/9/1 Camillo Bruni <camillo.bruni@inria.fr>:
Today on the train I was a bit bored on what I can do with CompiledMethodsâ¦
It seems like there are no inspection methods on CompiledMethods. Now I lets say I use Pharo from the command line (we're almost thereâ¦) then I would like to have a small interface to browse and navigate through methodsâ¦
(Object >> #at:) overrides    "return all direct overrides of this method" (Bag >> #at:) super       "return the method I override" (Bag >> #at:) superChain     "return all implementations in superclasses" (Object >> #name) senders (Object >> #name) implementors
instead of doing something like
SystemNavigation default allCallsOn: #name  "(BTW I would prefer allSendersOf: #name)"
What do you think? Does this make sense or not?
cami
I'm not convinced. (Object >> #name) senders 1) works only if you know a class that implements #name 2) technically it won't return the senders of (Object >> #name) but the senders of (AnyOtherClass >> #name)
Yes this is absolutely correct. But I think might have not been clear about my intentions. I do not want to replace SystemNavigation default * calls. But make sure that once you actually have a CompiledMethod you can browse from there on. Thats what the (Object >> #name) actually should mean, I should have chosen some better example like (String >> #printOn:) or so.
(Object >> #name) implementors 1) same as above, you must first know an implementorâ¦
Again, you start from an existing implementation (Object >> #name) just happens to be a random example..
(Bag >> #at:) super /superChain is a bit better, but there is again no garanty that Bag implements at:, still I might want to see all implementors in superclasses.
Nope, (Bag >> #at:) will fail if the method doesn't exist.
Nicolas
I guess what you want meant is the same navigation interface on Symbol:
#name implementors #foo:bar: senders #at: superChain: Bag      "definitely needs another name :)" #at: implementorsAbove: Bag  "might be betterâ¦"
cami
Yes, but this will reopen the Symbol/Selector thread ;)
Nicolas
participants (3)
-
Benjamin -
Camillo Bruni -
Nicolas Cellier