http://code.google.com/p/pharo/issues/detail?id=1775

...

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?

Indeed. Btw it would be cool to have a class definition also be stamped as well as any methods do. Because at the end, they're all about same thing: making a changes into the system. And as any well-logged change, it apparently, should carry the source text and having an author and date stamp. I guess, that class could store the sourcePointer to its own change recond in class organizer, in same way as it currently storing a comment there. Actually, i think we could use the comment's source pointer to also store a class definition in a single chunk:

Object subclass: #Blabal variablabla: ... poolVars: '' <empty line> "Here starts the class comment ... ... ... ... .. " << end of comment

...

Stef

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Best regards, Igor Stasenko AKA sig.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

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