[news.eclipse.modeling.m2m] Re: [QVTO]string operations and blackboxes

["Radek Dvorak" <radek.dvorak@xxxxxxxxxxx>]

Hi Adolfo,

Thanks for pinging me, I will join the discussion.

Our StdLib is just in the first phase, building a corresponding model for  
available StdLib elements (if possible ;-)).
The approach taken now it's not complete and just builds the model  
programmatically,
attaches adapters to operations - call handlers, written by hand in java ->
no QVT library source yet.
It's pretty fast call dispatching and no explicit switching code.

Actually, an analogous mechanism should be used in the next phase too.
The AST library model will be created from QVT concrete syntax -> from  
which
an ecore model representing the java impl will be generated.
In a next step - code generation - initially empty java operation skeletons
(later customized by the user) will be generated.
The binding of java operation impls to AST model will be done  
automatically when loading the library
for execution.

Basically, the user should write just operation headers etc. in QVT and a  
proper
java type binding should be generated automatically.

Perhaps sounds a bit complex, but it should not address the StdLib only  
but blackbox libs
in general. Also, the gen model to use and java impl binding might be  
replacable by
different kinds of impls, simple by extending a common extension point.

So at the moment, not too much to see as a complete picture of an approach  
in the code yet. ;-))

Actually, a uniform model approach made the StdLib content instantly and  
correctly applicable in the code-completion
which we have committed recently. So it's not a bad way to go ;-).

Regard,
/Radek



On Thu, 24 Apr 2008 15:25:54 +0200, Adolfo SÃnchez-Barbudo Herrera  
<adolfosbh@xxxxxxxxxxxxxxxx> wrote:

> Hi Radek,
>
> I have recently started (again ÂÂ!! ) a discussion in the OCL newsgroup  
> about the OCL and QVTo standard libraries. I precisely named you and  
> colleagues to join it ;).
>
> Since there isn't too many people working around this. It could be  
> interesting having several points of view, and try to align them to  
> improve the OMG specification... Oh they seem Ken's word ;P.
>
> I'm glad that you a have added the Std Lib to the CVS. I'll have to  
> download your code to contrast it with my approach ;).
>
> Cheers,
> Adolfo.
>
> Radek Dvorak escribiÃ:
> > Hi Cesar,
> >  We have already implemented complete String operatons set according to  
> > the spec.
> > But it was committed after M6, which you are apparently using.
> > We will produce integration build this week, so you could make use of  
> > it.
> >  Anyway, once the QVT standard library does not implement all you want,  
> > you have to blackbox it.
> > There was already mentioned meachism in this newsgroup -
> > see '[QVTO] Adding custom operations for primitive data types' topic.
> >  This is an old way of blackboxing (came from Borland initial  
> > contribution), we
> > plan to generate java skeletons from QVT operations headers.
> >  So far, there is a helper String library available in QVTO, you access  
> > it like this
> >      import library Strings;
> >  but most of its routine have been implemented in StdLib already.
> >   Regards,
> > /Radek
> >  On Thu, 24 Apr 2008 00:42:32 +0200, kaiserlautern  
> > <comouraf-lixo@xxxxxxxx> wrote:
> >
> > > Hi,
> > >
> > > I have strings like a<K->1,T->T1> and would like to separate  
> > > parameters (in this example, K and T) from their values (1 and T1).  
> > > Apparently, QVTO implements just a fraction of the string operations  
> > > proposed in the spec, making it very difficult (if possible at all) to  
> > > "tokenize" strings. So, is this a typical case for blackboxes? If so,  
> > > how to implement them? Is there any particularity or all I have to  
> > > write is a plain (java?) class implementing only the interface  
> > > declared in the qvt file? Where to put my classes?
> > >
> > > Thanks,
> > >
> > > CÃsar



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/