Hi Fabrizio,
Great.
The Importer has two parts:
- The SmalltalkImporter deals with all classes. It has these create* and ensure* methods
to deal with creating the actual entities. For this to work, it needs a Pharo model. For
example, in createClass, you ensure the associated package, but this is based on the
RPackage model.
ensure* methods make sure that you do not create twice the same entity so you should use
them each time you want to create an entity. I guess that you mean a Moose model.
- The visiting of method ASTs happens in the
SmalltalkMethodVisitor which is triggered by SmalltalkImporter>>createMethod:. It is
this visitor which is the responsible for triggering the creation of low-level objects
like invocations and accesses.
Yes.
As I see it, you would probably benefit from
subclassing both of these classes to deal with your input model and ASTs.
Yes but what is so different in VA Smalltalk code?
Because the AST should be nearly the same. Fabrizio did you encounter the static array or
something like that in VA because
we could have simply a Node to handle such case.
In the future, perhaps we can generalize a bit the
infrastructure to handle your case without dirty overrides.
What are the methods
that should be overriden?
Because yes providing hooks would be good.
Btw, would your code be open source?
I hope :)
Stef
Cheers,
Doru
On Feb 23, 2013, at 10:57 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote:
Hi again,
I'm developing a parser for VA .app files and .st files. I'm using
PPSmalltalkParsers to parse smalltalk methods but I need to enrich
these objects with more information so I specialized RBMethodNode to
add the info I need. The question is now, what about the importer? Is
there any I can reuse that compute already method invocations and
accesses or I should write a brand new one?
Cheers,
Fabrizio
2013/2/21 Fabrizio Perin <fabrizio.perin(a)gmail.com>om>:
Hi,
thanks for the responses. I think I will go for the second option
proposed by Doru but first I would like to check this Rossetta stuff
which supports VA to squeak export.
The only think that make me scheptical is that the VA Smalltalk have
concepts that are not in squeak. i.e. in VA you can have private
methods and there is this concept of application. So I don't know if
the RB AST is expressive enough and, most of all, if the importer will
actually import this kind of info.
Let you know how it goes.
Cheers,
Fabrizio
2013/2/20 Chris Cunningham <cunningham.cb(a)gmail.com>om>:
> Hi.
>
> On Wed, Feb 20, 2013 at 4:01 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com>
> wrote:
> <snip>
>>
>> - Should I customize the PPSmalltalkParser or should I start a parser
>> from scratch?
>> - Did anybody tried to import in moose a smalltalk dilect different
>> from pharo? If yes how did he do that?
>>
>> I just want to understand if I can save time or I should build a whole
>> parser and importer from scratch.
>
>
> I've done similar work (except from VSE Smalltalk). My path was to use port
> the code to moose first, then work with it in the image. The tool I use
> doesn't appear to be readily available anymore, but there are other options,
> such as:
>
>
http://rosettast.sourceforge.net/
> (this that might support VisualAge to Moose already)
>
>
https://github.com/CampSmalltalk/Cypress
> (those doesn't appear to currently support VisualAge to Moose, but has been
> active recently)
>
> I have not used either of these, though.
>
> Enjoy,
> Chris
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev