Hi eliot
my approach to this is to define ClassReference that sits alongside MethodReference and so allows the list browser tools (list browser, change list, etc) to compare class definitions. If you think this makes sense let me know and I'll extract the code (I no longer have a change set; this code is now integrated into our images).
Yes at least this is coherent. How different are there from PseudoClass? Now don't you feel that it makes a lot of wrapper code? We had crazy discussions with marcus about MethodReference and CompiledMethod: meta object and object, runtime objects and ui objects, their causal connection. At one point we will have to clean that. I do not know in which direction. At least they should have a common interface selector class and we have that now in pharo so to a minimal but useful extent we can manipulate CM as MR and the inverse. Power to polymorphic interfaces. Brainstorming we could merge CompiledMethod and MethodReference if we do not need extra state and methodReference protocol can be packaged as an extension of compiledMethod and the behavior is ok (like manipulating a MethodReference which is not "installed" in the system) Now the same question arise with Class and ClassReference. In the same vein (but inverse logic) I was thinking that it would be cool that MCClassDefinitions share a common interface with Class and Pseudo class so that we could only only one browser to browse them all. After of course the two objects could have their own specific interface in addition to the share one. Now a potential problem is the mapping between a declarative code model (MC) and a runtime one in term of mismatch: MCVariableDefinition and no object to represent instance variables. Of course we want first class instance variable at the MOP level and it will come. But this mismatch is a problem I know and did not check any further.
On Mon, Jan 11, 2010 at 8:11 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Yep! I will do that Stef On Jan 11, 2010, at 4:49 PM, Gary Chambers wrote:
Saw that too. One or the other! Defniniton perhaps (also on PackageInfo would do the lot).
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, January 11, 2010 2:57 PM Subject: [Pharo-project] definition or getSource for Class and CompiledMethod
Hi
I was looking at the video of laurent and what stroke me is that getting the source of class or a compiled method is not polymorphic. It would be good to support that. aClass getSource? aCompiledMethod definition?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project