Thomas, I've edited the Wiki section http://wiki.eclipse.org/Query_Language_for_p2#Language_Design and would appreciate if you could take a quick read through it to make sure that what I wrote was (a) correct, and (b) understandable.
Thanks and Regards, Dave On Tue, Dec 14, 2010 at 6:12 PM, Thomas Hallgren <[email protected]> wrote: > Hi David, > > > On 2010-12-14 23:45, David Orme wrote: > > Thomas, > > I'm writing: > > (a) to provide some hopefully constructive feedback on p2ql, and > > (b) because there were two aspects of the p2ql we had to work out for > ourselves and if they're documented, we couldn't find them. :) I'm writing > to confirm our understanding so that we can update the p2ql wiki page with > these bits if that is necessary. > > > That would be really helpful. I'd be happy to answer more questions and > help you along in that effort. > > > > > ------------ > > (a) > > We liked p2ql because it separates the concerns of querying for IUs from > what you do with the IUs after you've queried for them really cleanly. It > also feels like a natural compliment to our existing API--by adding > abstraction that makes common querying use cases simple. > > > I'm glad you like it. One of the objectives was to enforce a cleaner > separation. Both to benefit client frameworks like yours and also to enable > future enhancement to how queries are evaluated and how IU's are stored etc. > > > > (b) > > We couldn't find anywhere in either the bug report nor on the Wiki that > described how external Java objects are bound into p2ql. Here's my current > understanding: > > - p2ql is a dynamically typed language in Smalltalk's tradition: It > just has receivers and messages, but no data types per se. > - p2ql is a strictly functional language. No assignments, but > higher-order functions all over the place. Syntax reminds strongly of > Scala. :-D > > > > - $0, $1, ..., $n refer to the Java objects passed in as query > parameters. > - An unqualified variable or function call refers to the IQueryable's > collection. > - e.g.: select(iu | ....) is the same as saying > rootQueryable.select(iu | ...) if Java had proper higher-order > functions. > > Correct. I can add that for a full query you will have the implicit > variable 'everything' so select(iu | ...) is the same as > everything.select(iu | ...). For a boolean match query (executed on a > per-row basis), the implicit variable is called 'this', so name == $0 is the > same as this.name == $0 > > > > > > > > - If a message's receiver is an Iterable or an IQueryable, the message > must be a higher-order function that iterates across the elements. > - ie: if $0 is an ArrayList of IVersionedId, $0.exists(vi | vi.id == > 'com.some.bundle') will iterate over $0's elements and return true iff > "com.some.bundle" is the ID of an element inside the list. > - Otherwise, dot notation calls getters on the receiver. e.g.: if $0 > is an IVersionedId, $0.id is the same as writing param0.getId() in > Java. > > Have I got that straight? Am I missing anything? > > It all sounds correct. For the dot notation, the 'length' and 'empty' can > be used on all types of collections and arrays. And analog to how beans > work, a boolean isser is resolved too, i.e. the Java method iu.isFragment() > can be referenced as iu.fragment. > > Regards, > Thomas Hallgren > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > >
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
