hi, i really like the idea, quite a challenge :) But since you ask for our opinion I really dont like some of the methods' names specially the ones using "the" as prefix.
Regards, Francisco On Sat, Dec 11, 2010 at 1:17 AM, Yanni Chiu <[email protected]> wrote: > On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote: > >> Dear all, >> >> I am currently working on the *Ring*, an unifying and foundational model >> infrastructure for Pharo. >> The goals are: >> - Provide a common API at structural and runtime level >> - Allow tools to interact and integrate directly with the host >> environment (Pharo) >> - Support history analysis >> >> I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, >> Smalltalk itself and Ginsu, as a basic to build the Ring. >> So far I have implemented the main classes including the ones that >> should replace MethodReference and the Pseudo classes. >> >> An unified API will imply changes in most of the ones mentioned above >> (as most of them are non-polymorphic). >> As a first step, I would like to have your opinion about the proposal >> for replacing MethodReference (attached file). >> > > I'm not clear on what "Ring" is going to be, and I've looked at > MethodReference for the first time, just now. Coming up with the names for > things is a big part of creating an object information model (i.e. analysis > model). The context of how ORCompiledMethodDefinition fits into the overall > model would help to figure out the names. > > Generally, I use "theSomething" as a last resort. And, typically it's for a > temp var or method argument - rarely, if ever, for an object attribute > (a.k.a. instVar). So, actualClass --> theClass, is a don't like. > > The method definition is neither meta nor non-meta - the associated class > can be meta. Suppose the meta-class hierarchy were eliminated, should the > method definition still make sense in that scenario. I think classIsMeta is > more clear than isMeta. > > classSymbol --> className - yes > methodSymbol --> selector - yes > > sourceString, sourceCode --> source - no, why not keep sourceCode, and > avoid the confusion of redefining "source". Or, maybe rawSource and > formattedSource could be used. > > source --> formattedSource - yes > > stringVersion --> fullName - not sure, but if there's version info in the > name, I think "version" should be used in the name > > I don't understand the talk about methodClass, objectClass, variableClass, > commentClass. > > Hope that helps. > > >
