> 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 <[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.
>>
>>
>>
>
>