On 11 Dec 2010, at 10:33, Stéphane Ducasse wrote: > > On Dec 11, 2010, at 6:47 AM, Francisco Ortiz Peñaloza wrote: > >> 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. > > what is the alternative? > class?
#itsClass #parentClass (suggested by Tudor) > No it does not work > (Point>>#x) class -> CompiledMethod > and we want > (Point>>#x) theClass -> Point > > > (Point>>#x) asMethodDefinition class -> MethodDefinition > and we want > (Point>>#x) asMethodDefinition theClass -> aClassDefinition for Point > > >> >> 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. >> >> >> > >
