[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] p2 QL feedback / discussion
|
I see that the method was renamed to "toUnmodifiableSet"
which definitely makes a difference. However, the javadoc needs to
tell users to prefer one over the other for performance reasons. When
using a new API I am going to use the simplest method I can find that does
what I want, not look for performance optimizations.
Curtis
From:
| Thomas Hallgren <thomas@xxxxxxx>
|
To:
| p2-dev@xxxxxxxxxxx
|
Date:
| 2010/02/27 04:25 AM
|
Subject:
| Re: [p2-dev] p2 QL feedback / discussion
|
Sent by:
| p2-dev-bounces@xxxxxxxxxxx |
Another concern:
Most new code that has been added since we changed the IQueryResult interface
tend to use the expensive toSet() method instead of the unmodifiableSet()
method. Example:
someCollection.addAll(queryResult.toSet());
instead of the much cheaper:
someCollection.addAll(queryResult.unmodifiableSet());
The toSet() creates a full copy of the result while the unmodifiableSet()
doesn't. This is stated in the javadoc but perhaps it needs to be more
clear? Or should we change the method names?
- thomas
On 02/26/2010 09:02 PM, Pascal Rapicault wrote:
Personally I'm worried about the learning curve to new
comers (and old comers as well :)) because I now have to learn a language
to do something simple that I use to be able to do with a bit of code.
Therefore I was thinking that it may be interesting to
add new helper queries to do things like:
- find an IU whose ID contains a string instead of being
a full match.
- find an IU that has a set of capability
Also we need to have a bunch of little example explaining
what they do in addition to a more descriptive guide of the syntax. Also
being able to relate the language to something known (e.g. OCL) could help.
Now from a code maintainer point of view, this language
is part of the API. So it brings 2 questions:
- how to we evolve it in a backward compatible way? not
really an urgent matter but still.
- do we leak any implementation detail? Are we too close
to the actual data structure. For example I see references to IInstallableUnitPatch.class
or such. Can't we avoid this?
PaScaL
On 2010-02-26, at 11:32 AM, Thomas Watson wrote:
I have a concern about how closely the syntax is tied to
the repository metadata syntax and the data structure of the IU. For example,
how you search for the latest versions of all the UIs that provide the
osgi.bundle capability goes something like this:
latest(x | x.providedCapabilities.exists(p | p.namespace == 'osgi.bundle'))
My understanding is that this will return all the latest versions of the
IUs that provide the capability with the namespace of osgi.bundle. So there
are a couple of concerns I can see if this QL is expected to work for all
future releases of p2.
- IUs must always have a way to get the list of provided capabilities using
the .providedCapabilities syntax. (probably pretty safe bet?)
- Capabilities must always have something called a namespace. Not sure
if this is always going to be true. I guess even OBR will have resources
(capabilities) that provide some kind of name space.
- The name space value becomes API. 'osgi.bundle' must always be the namespace
to represent a bundle. AFAICT there is no place in the p2 API that lists
the namespace values as API. The feel like they are an internal detail
to me.
I also don't see any documentation on the various fields that can be used
in a query (.providesCapabilities, .namespace etc.) and what their corresponding
types are.
Tom
<graycol.gif>Pascal Rapicault ---02/26/2010
09:55:33 AM---With the latest changes that Thomas committed this week,
we are now fully p2 QL enabled. Thank you.
<ecblank.gif>
From:
| <ecblank.gif>
Pascal Rapicault <pascal@xxxxxxxxxxxx>
|
<ecblank.gif>
To:
| <ecblank.gif>
P2 developer discussions <p2-dev@xxxxxxxxxxx>
|
<ecblank.gif>
Date:
| <ecblank.gif>
02/26/2010 09:55 AM
|
<ecblank.gif>
Subject:
| <ecblank.gif>
[p2-dev] p2 QL feedback / discussion |
With the latest changes that Thomas committed this week, we are now fully
p2 QL enabled. Thank you.
Overall this is a good step forward and bring to p2 a really neat point
of flexibility. However before we wrap up on the API, I'm soliciting feedback
on it. What do you think of it, what are your worries, are there any simple
things we can do?
PaScaL_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev