Hi, On 11 Dec 2010, at 12:24, Tudor Girba wrote:
> 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. I have an alternative #itsClass, but #parentClass is a good suggestion. > >> 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? No version or time info is kept in stringVersion.. This name is completely wrong. > >> 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 > Like the idea.. > 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. > A compilation process defined in Behavior is using it.. Maybe I will change it and remove #methodClassAssociation > Cheers, > Doru > > Thanks :) > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > >
