thanks gisela I love so much the suggestions :) Stef
On Nov 8, 2013, at 11:28 AM, Gisela Decuzzi <[email protected]> wrote: > Ok, it would be nice to avoid using the parser directly. > But we can change it in the future, for now we have a new version for > https://pharo.fogbugz.com/f/cases/10983/Represent-a-class-definition-with-AST-structure > in inbox. > > Thanks! > > > 2013/11/8 Marcus Denker <[email protected]> > > On 07 Nov 2013, at 22:14, Gisela Decuzzi <[email protected]> wrote: > > > Hello, we were working on the issue 10983 plus smart suggestion, specially > > for a class definition. > > In a moment I need to parse a class definition, I treat as the normal case: > > root := OpalCompiler new > > source: context code; > > useFaultyForParsing: true; > > parse. > > And as a result we obtain a Method Node, browsing the code we saw that Opal > > can parse code as an expresion, but instead it is treating the code as > > method because of: "self compilationContext noPattern" is false, when we > > changed the boolean to true we obtain a return node for the class > > definition and everything got messy. > > > > Can someone help us to use Opal in the right way? > > > > The problem is that #noPattern is only used for compiling DoIts, and those > are more than just an expression (return added, access to temps rewritten…). > > So for now, the best (yet ugly) thing is to just use RBParser directly, and > we later have to think a bit about the API of the OpalCompiler facade, > especially > considering it is both a facade to just the parser *and* to the compiler, and > e.g expression parsing is very different from parsing a doit, even though one > would think they are the same. > > So for now, just use the RBParser directly, I would say (there are lots of > direct users of it, we can only remove them in Pharo4 when we have just one > AST). > > Marcus > > >
