>
> Regards,
> Francisco
>
> On Sat, Dec 11, 2010 at 1:17 AM, Yanni Chiu <[hidden email]> 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.
>
>
>