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.shea...@gmail.com> > wrote: > On 10 February 2013 16:25, Camillo Bruni <camillobr...@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
