[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] p2ql wiki page
|
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
<thomas@xxxxxxx> 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
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev