Le 25/07/2014 23:46, Marcus Denker a écrit :
On 25 Jul 2014, at 23:44, Marcus Denker <marcus.denker@inria.fr> wrote:
On 25 Jul 2014, at 23:28, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 25/07/2014 23:15, Marcus Denker a écrit :
On 25 Jul 2014, at 21:51, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Le 25/07/2014 21:42, kilon alios a écrit :
ok we are getting somewhere, the problem is that if I do
(SomeClass compiledMethodAt: #nameOfMethod it will look only in the instance side for method, how I look also for class methods ? Also how I can return source of class ? to be specific I need the names of instance variables, class variables and class instance variables . For the class method:
SomeClass class compiledMethodAt: #nameOfClassMethod
For the instance variable, etc... SomeClass definition will give you that. But it's a bit tricky to parse; for example, if you want a reification (instance variable name is recognized as instance variable name in the ast), I have some code which does: parse, rewrite and reparse on a class definition (for the smart suggestion thing).
Yes, we need that⦠there is code on the issue tracker, too:
https://pharo.fogbugz.com/f/cases/10983/Represent-a-class-definition-with-AS... Yes. What about the class definition format change described by Camillo? Slowly working on it⦠very early (and right now broken) stage is in the image. And it is not yet decided how it will look like exactly⦠the only thing clear is that we need to use
{#ivar1. #ivar2 . #boolean => BooleanSlot }
instead of the strings⦠both for ivars and class vars⦠I want to finish and debug the machinery around and then start to play with it.
I am a bit tempted to go the âbackward compatibleâ way and not use the term Slot but something like this:
TestCase subclass: #RBProgramNodeTest instanceVariables :{#ivar1. #ivar2 . #boolean => BooleanSlot } classVariables: {#MyGlobal} category: 'AST-Tests-Coreâ I'd be tempted not to write an adhoc mini-language inside the instanceVariables array. Why not just something like:
TestCase subclass: #RBProgramNodeTest instanceVariables :{#ivar1. #ivar2 . BooleanSlot named: #boolean } classVariables: {#MyGlobal} category: 'AST-Tests-Coreâ Maybe, with packages: TestCase subclass: #RBProgramNodeTest instanceVariables :{#ivar1. #ivar2 . BooleanSlot named: #boolean } classVariables: {#MyGlobal} package: #'AST-Tests-Coreâ Not much more: we can allways drag and drop to the right place if needed, query if no package is given, cut and paste for keyboard use. If you want the grand show, I'll make you a wizard for creating classes with at least 10 steps ;)
Ah, and we need to think about âcategoryâ⦠as we now have packages.
But for the âwe need some kind of AST like structureâ it changes nothing: this is still a message send, but we need to reason about a class definition if we want to have suggestions (and with them e.g. BreakPoints on variables) working.
Marcus
I have that working without a real "ClassDefinition node" at the moment. Really very convenient to have the refactorings on instance variables working straight out of the class description text pane by just selecting the instance variable name in the string. Class definitions are either normal messages (for example in code creating a class by hand) or descriptions visible in browsers (interactive use). In the first case, you should not interpret them as class definitions since the class may/probably does not exist at that point. It is then just a message. In the second case, the GUI can ask for interpretation of the message into a class definition. I think this is how Gisela solution works, no? Thierry