[Pharo-project] SystemNavigation >> #allSelect:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
On 10 févr. 2013, at 17:25, Camillo Bruni wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Yes, it's really boring to get methods back from these strings. +1 for changing this and rename the method allMethodSelect:.
On 10 February 2013 16:25, Camillo Bruni <camillobruni@gmail.com> wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Probably because the things that use SystemNavigation - Browsers, MessageSets and the like - want to render lists of things to the user. There is one advantage to dumb strings, which is that it's easy to make a SystemNavigation that works against a remote image. But that's not much to go on. Changing these kinds of methods to return MethodReferences might be a useful middle ground (and permit easy extension to remote tools). I mention remote tools because I hacked up a proof of concept a while back that turned a Browser into one that could access a suitably prepared image through an HTTP API. Development stalled because the reflection machinery's API is a bit... involved, and it was dog slow, but I could browse anything I liked. I should really wrap up the work a bit so I can spread the love. frank
On 2013-02-10, at 17:42, Frank Shearar <frank.shearar@gmail.com> wrote:
On 10 February 2013 16:25, Camillo Bruni <camillobruni@gmail.com> wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Probably because the things that use SystemNavigation - Browsers, MessageSets and the like - want to render lists of things to the user.
There is one advantage to dumb strings, which is that it's easy to make a SystemNavigation that works against a remote image. But that's not much to go on. Changing these kinds of methods to return MethodReferences might be a useful middle ground (and permit easy extension to remote tools).
I mention remote tools because I hacked up a proof of concept a while back that turned a Browser into one that could access a suitably prepared image through an HTTP API. Development stalled because the reflection machinery's API is a bit... involved, and it was dog slow, but I could browse anything I liked. I should really wrap up the work a bit so I can spread the love.
we have RBMethodDefinitions now, which are almost polymorphic to CompiledMethod when it comes to all inspection / reflection accesses. So I guess we can change that in 3.0 at some point to no longer return silly strings...
On Feb 10, 2013, at 5:46 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-02-10, at 17:42, Frank Shearar <frank.shearar@gmail.com> wrote:
On 10 February 2013 16:25, Camillo Bruni <camillobruni@gmail.com> wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Probably because the things that use SystemNavigation - Browsers, MessageSets and the like - want to render lists of things to the user.
There is one advantage to dumb strings, which is that it's easy to make a SystemNavigation that works against a remote image. But that's not much to go on. Changing these kinds of methods to return MethodReferences might be a useful middle ground (and permit easy extension to remote tools).
I mention remote tools because I hacked up a proof of concept a while back that turned a Browser into one that could access a suitably prepared image through an HTTP API. Development stalled because the reflection machinery's API is a bit... involved, and it was dog slow, but I could browse anything I liked. I should really wrap up the work a bit so I can spread the love.
we have RBMethodDefinitions now, which are almost polymorphic to CompiledMethod when it comes to all inspection / reflection accesses.
There is Ring that can do the same, too. We need to continue merging all the meta models⦠Marcus
On 2013-02-10, at 17:52, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 10, 2013, at 5:46 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-02-10, at 17:42, Frank Shearar <frank.shearar@gmail.com> wrote:
On 10 February 2013 16:25, Camillo Bruni <camillobruni@gmail.com> wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Probably because the things that use SystemNavigation - Browsers, MessageSets and the like - want to render lists of things to the user.
There is one advantage to dumb strings, which is that it's easy to make a SystemNavigation that works against a remote image. But that's not much to go on. Changing these kinds of methods to return MethodReferences might be a useful middle ground (and permit easy extension to remote tools).
I mention remote tools because I hacked up a proof of concept a while back that turned a Browser into one that could access a suitably prepared image through an HTTP API. Development stalled because the reflection machinery's API is a bit... involved, and it was dog slow, but I could browse anything I liked. I should really wrap up the work a bit so I can spread the love.
we have RBMethodDefinitions now, which are almost polymorphic to CompiledMethod when it comes to all inspection / reflection accesses.
There is Ring that can do the same, too. We need to continue merging all the meta modelsâ¦
right, that's what I meant: RGMethodDefinition
+9000 Ben On Feb 10, 2013, at 5:45 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-02-10, at 17:42, Frank Shearar <frank.shearar@gmail.com> wrote:
On 10 February 2013 16:25, Camillo Bruni <camillobruni@gmail.com> wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Probably because the things that use SystemNavigation - Browsers, MessageSets and the like - want to render lists of things to the user.
There is one advantage to dumb strings, which is that it's easy to make a SystemNavigation that works against a remote image. But that's not much to go on. Changing these kinds of methods to return MethodReferences might be a useful middle ground (and permit easy extension to remote tools).
I mention remote tools because I hacked up a proof of concept a while back that turned a Browser into one that could access a suitably prepared image through an HTTP API. Development stalled because the reflection machinery's API is a bit... involved, and it was dog slow, but I could browse anything I liked. I should really wrap up the work a bit so I can spread the love.
we have RBMethodDefinitions now, which are almost polymorphic to CompiledMethod when it comes to all inspection / reflection accesses.
So I guess we can change that in 3.0 at some point to no longer return silly strings...
On Sun, Feb 10, 2013 at 8:42 AM, Frank Shearar <frank.shearar@gmail.com>wrote:
On 10 February 2013 16:25, Camillo Bruni <camillobruni@gmail.com> wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Probably because the things that use SystemNavigation - Browsers, MessageSets and the like - want to render lists of things to the user.
There is one advantage to dumb strings, which is that it's easy to make a SystemNavigation that works against a remote image. But that's not much to go on. Changing these kinds of methods to return MethodReferences might be a useful middle ground (and permit easy extension to remote tools).
No, dumb strings are dumb. A className, selector pair (which is what MethodReference is) is the right thing (and what systemNavigation methods return). The dumb strings are a pain in the ass to parse (endlessly looking for ' class' to spot meta classes etc). Whereas the class,selector p[air approach is extensible, e.g. to include a pointer to a specific external entity (be it Monticello package or remote image). MethodReference is what the system has provided for a decade and they're convenient. There are multiple versions of these and I could care less about whether one uses MethodReference or RBMethodDefinition. But that they have a consistent API is really important. Programmatic uses of these things for code editing is something I've depended upon in the VMMaker, and I'm anxious that Pharo and Squeak don't diverge hopelssly on this level of the system. In my own work I've ended up with three kinds of code reference object a) MethodReference that points to a class,selector pair b) ClassReference that points to a class c) TextReference that holds onto a text So if one wants to check out a refactoring/edit before applying it one compares a sequence of MethodReference objects and a matching sequence of TextReference objects that hold onto the edited source to a comparison engine. If one wants to have a look at all uses of a SharedPool one can supply a list of ClassReference objects to a list browser. If one wanted to build a "compare two images" or "compare arbitrary package versions: facility one can extend the reference objects with pointers to specific packages or remote images. etc. Lots of stuff in the system depends on these kinds of pointer; message list browsers, Monticello's loader, etc. What's insane is a) not having a standard set of facilities common between Pharo and Squeak with a well-defined API (e.g. isCodeReference, isMethodReference, isClassReference), b) having some of the API in extension methods in e.g. Monticello. This is core reflection protocol and it needs to be well-defined and in what ever package contains base reflection protocol. excuse my ranting.
I mention remote tools because I hacked up a proof of concept a while back that turned a Browser into one that could access a suitably prepared image through an HTTP API. Development stalled because the reflection machinery's API is a bit... involved, and it was dog slow, but I could browse anything I liked. I should really wrap up the work a bit so I can spread the love.
frank
-- best, Eliot
Hi eliot We worked on Ring for more than a year and it is a complete source code meta model and it is just to remove pseudo class and the rest. We should check for the TextReference idea. Stef
On Sun, Feb 10, 2013 at 8:42 AM, Frank Shearar <frank.shearar@gmail.com> wrote: On 10 February 2013 16:25, Camillo Bruni <camillobruni@gmail.com> wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Probably because the things that use SystemNavigation - Browsers, MessageSets and the like - want to render lists of things to the user.
There is one advantage to dumb strings, which is that it's easy to make a SystemNavigation that works against a remote image. But that's not much to go on. Changing these kinds of methods to return MethodReferences might be a useful middle ground (and permit easy extension to remote tools).
No, dumb strings are dumb. A className, selector pair (which is what MethodReference is) is the right thing (and what systemNavigation methods return). The dumb strings are a pain in the ass to parse (endlessly looking for ' class' to spot meta classes etc). Whereas the class,selector p[air approach is extensible, e.g. to include a pointer to a specific external entity (be it Monticello package or remote image). MethodReference is what the system has provided for a decade and they're convenient. There are multiple versions of these and I could care less about whether one uses MethodReference or RBMethodDefinition. But that they have a consistent API is really important. Programmatic uses of these things for code editing is something I've depended upon in the VMMaker, and I'm anxious that Pharo and Squeak don't diverge hopelssly on this level of the system.
In my own work I've ended up with three kinds of code reference object
a) MethodReference that points to a class,selector pair b) ClassReference that points to a class c) TextReference that holds onto a text
So if one wants to check out a refactoring/edit before applying it one compares a sequence of MethodReference objects and a matching sequence of TextReference objects that hold onto the edited source to a comparison engine.
If one wants to have a look at all uses of a SharedPool one can supply a list of ClassReference objects to a list browser.
If one wanted to build a "compare two images" or "compare arbitrary package versions: facility one can extend the reference objects with pointers to specific packages or remote images.
etc.
Lots of stuff in the system depends on these kinds of pointer; message list browsers, Monticello's loader, etc.
What's insane is a) not having a standard set of facilities common between Pharo and Squeak with a well-defined API (e.g. isCodeReference, isMethodReference, isClassReference), b) having some of the API in extension methods in e.g. Monticello.
This is core reflection protocol and it needs to be well-defined and in what ever package contains base reflection protocol.
excuse my ranting.
I mention remote tools because I hacked up a proof of concept a while back that turned a Browser into one that could access a suitably prepared image through an HTTP API. Development stalled because the reflection machinery's API is a bit... involved, and it was dog slow, but I could browse anything I liked. I should really wrap up the work a bit so I can spread the love.
frank
-- best, Eliot
done On 2013-02-10, at 20:14, stephane ducasse <stephane.ducasse@free.fr> wrote:
open an issue for 3.0 so that we do not forget
Stef
On Feb 10, 2013, at 5:25 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
On Sun, Feb 10, 2013 at 8:25 AM, Camillo Bruni <camillobruni@gmail.com>wrote:
Why does SystemNavigation >> #allSelect: return strings of the form 'Array at:' instead of the real methods?
Because its broken. But it shouldn't return real methods. It should return MethodReference instances (or their equivalent, RBMethodDefinition), as do all the other systemNavigation facilities. -- best, Eliot
participants (7)
-
Benjamin -
Camille Teruel -
Camillo Bruni -
Eliot Miranda -
Frank Shearar -
Marcus Denker -
stephane ducasse