Hi, Nice initiative. I added my comments below.
On 11 Dec 2010, at 04:17, Yanni Chiu 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. I would suggest parentClass. > 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. In Moose we have isMetaSide / isInstanceSide. > 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. I also agree that sourceCode is better. > 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 #fullName implies that you will get a meaningful name, but the version is not part of the name. But, why do we actually need this stringVersion method? Why not have a #timestamp method instead, and then use that when you want to print the information? > I don't understand the talk about methodClass, objectClass, variableClass, > commentClass. I would rename is #methodClass to #parentClass. I would keep or rename the followings: #methodReference -> #reference #methodNode -> #node As for #methodClassAssociation:, I think it is better to keep it like it is, but my question is why do we actually need this ugly method. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow."
