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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2010/1/11 Stéphane Ducasse <[hidden email]>:
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Saw that too.
One or the other! Defniniton perhaps (also on PackageInfo would do the lot).

Regards, Gary

----- Original Message -----
From: "Stéphane Ducasse" <[hidden email]>
To: <[hidden email]>
Sent: Monday, January 11, 2010 2:57 PM
Subject: [Pharo-project] definition or getSource for Class and
CompiledMethod



_______________________________________________
Pharo-project mailing list
[hidden email]
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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Steph,
_______________________________________________
Pharo-project mailing list
[hidden email]
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.



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project