On 26 Jul 2014, at 00:00, Thierry Goubier <thierry.goub...@gmail.com> wrote:
> Le 25/07/2014 23:46, Marcus Denker a écrit : >> On 25 Jul 2014, at 23:44, Marcus Denker <marcus.den...@inria.fr> wrote: >> >>> On 25 Jul 2014, at 23:28, Thierry Goubier <thierry.goub...@gmail.com> wrote: >>> >>>> Le 25/07/2014 23:15, Marcus Denker a écrit : >>>>> On 25 Jul 2014, at 21:51, Thierry Goubier <thierry.goub...@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-AST-structure >>>> 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: > What I like with the #name=>Var notation is that it puts the name of the variable first. And it is just an expression (you can evaluate it, it’s the same as BooleanSlot named: #boolean) So it is just an expession, and e.g. classes could create slots: {Integer typedSlotNamed: #i} > 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? > Yes! Marcus
