Re: VOTE graduation (was Re: Next steps? (was Re: Is trinidad ready for graduation ?))
[X] graduate as a subproject of the Apache MyFaces community [ ] graduate as a TLP [ ] not ready to graduate, because... On 12/04/07, Grant Smith [EMAIL PROTECTED] wrote: [X] graduate as a subproject of the Apache MyFaces community [ ] graduate as a TLP [ ] not ready to graduate, because... On 4/11/07, Adam Winer [EMAIL PROTECTED] wrote: [X] graduate as a subproject of the Apache MyFaces community [ ] graduate as a TLP [ ] not ready to graduate, because... On 4/11/07, Jeanne Waldman [EMAIL PROTECTED] wrote: [X] graduate as a subproject of the Apache MyFaces community [ ] graduate as a TLP [ ] not ready to graduate, because... Simon Lessard wrote: [X] graduate as a subproject of the Apache MyFaces community [ ] graduate as a TLP [ ] not ready to graduate, because... On 4/11/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: [X] graduate as a subproject of the Apache MyFaces community Craig PS: Note that binding is only relevant on release votes, where it's a PMC member doing the voting. For procedural issues (like this one), all committers are equal. -- Grant Smith
Re: [Fwd: Re: return an Iterator vs a List]
I agree with Blake. We'll get ourselves into trouble is we begin
switching objects around, because if people need the other access
methods they'll do a cast and we'll break them.
Furthermore, if we use the generic Collections (like List, Set, etc.)
then it is more clear as to what constraints are on returned data. A
set, for instance, cannot have duplicate items, etc. etc. These are
things that we best not violate, contractually, within the API.
Scott
Blake Sullivan wrote:
Adam Winer wrote:
I don't think there's that much reason not to return
a List. All I'm saying is that if you had an API
that was Iterator, and your desire was to support
the fun SE 5 for construct, then Iterable is the
simplest change. The question then is why the
original API was ever Iterator, and if it should
have been List, or Collection, etc.
In looking at the code, it doesn't appear to have been much rhyme or
reason to when we returned Iterators or even arrays. For the methods
that currently return Iterators, my point is that the big step is
agreeing to return Iterables instead (switching from Iterators to a
factory for Iterators). Once you decide to return Iterables for
immutable objects, then you might as well return the correct
Collection classes--Collection, List, Set as returning these classes
places no additional api burden on the implementor as I believe that
even in the worst case where the implementor only had an Iterable and
not the actual Collection class in question, a simple adapter could be
written to convert an Iterable into the appropriate unmodifiable
Collection class.
-- Blake Sullivan
I'm not thrilled with exposing List if you think that
you might someday want it to be a Set - Collection
is safer in that regard.
-- Adam
On 4/9/07, Blake Sullivan [EMAIL PROTECTED] wrote:
Adam,
Actually the reason for the switch to List versus Iterable would be for
general convenience of developers consuming the api (with efficiency a
much smaller issue).
Which methods on java.util.List do you think are providing too broad of
a contract? Do you believe that returning a List is limiting the
implementations choices severely enough that it outweighs the
convenience of using a Collection class?
-- Blake Sullivan
Jeanne Waldman wrote:
three out of six
Original Message
Subject: Re: return an Iterator vs a List
Date: Wed, 4 Apr 2007 15:42:17 -0700
From: Adam Winer [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
If the only reason is to enable the fun new for syntax,
then we should change the type from Iterator to Iterable,
instead of List. List is a much larger contract.
-- Adam
On 3/28/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I'm in the Skinning StyleNode code and I see that the 'get' methods
return Iterators
from the good ol' days.
It seems to me that it is better if they just return Lists so the
code
that iterates over
the values is cleaner using 5.0's for(String foo : yyy) construct.
Does anyone see why I wouldn't want these to return List instead of
Iterator?
Here's a code snippet. Thanks, Jeanne
--
public IteratorIncludePropertyNode getIncludedProperties()
{
if(_includedProperties == null)
{
ListIncludePropertyNode list = Collections.emptyList();
return list.iterator();
}
else
return (Arrays.asList(_includedProperties)).iterator();
}
/**
* Gets the properties specified by this node's parent that
should be
* ignored. This method will return an empty iterator if
* [EMAIL PROTECTED] #isInhibitingAll()} returns codetrue/code
*
* @return an iterator over the properties that should be
ignored, an
* empty iterator if all properties should be.
*/
public IteratorString getInhibitedProperties()
{
if(_inhibitedProperties == null)
{
ListString list = Collections.emptyList();
return list.iterator();
}
else
{
return _inhibitedProperties.iterator();
}
}
Re: VOTE graduation (was Re: Next steps? (was Re: Is trinidad ready for graduation ?))
+1 to start graduating :) Mvgr, Martin Matthias Wessendorf wrote: Hello Trinidad PPMC members and Trinidad community, [X] graduate as a TLP
Re: Next steps? (was Re: Is trinidad ready for graduation ?)
And a jakarta-style JSF components project. Let's assume we start the myfaces commons stuff in the near future, this JSF components TLP could have the following subprojects: -Tomahawk -Tobago -Trinidad -commons (non-renderkit-goodies) Martin, you are the man that know best about Jakarta, what are your thoughts on that? I won't bore you with the details that don't matter in this discussion and I won't state here that I know best, just because I am VP of Jakarta. First of all : - Jakarta is very big with about 109 projects and almost everyone at the ASF is committer, yes even you Matthias. - Jakarta has big PMC. In our scenario committers are not automatically on the PMC (there are projects doing that). Besides the benefits of being on the PMC (legal protection, binding votes on release, etc) you also have the obligation to give oversight to the project you are on the PMC for. Let's sketch a MyFaces scenario, with me as a potential committer. - I send a lot of patches for Trinidad - You get sick and tired of me and start a committer vote, so I can start applying patches myself. - I am a committer on the MyFaces TLP now. Even though I don't care about the JSF impl, I am committer there (ignoring svn karma rules that may have been set up) - If I end up on the PMC I am only interested in representing Trinidad (in fact I am just a Trinidad committer), so in fact I am not representing and giving oversight to the complete MyFaces TLP project. - The disconnect has happened between oversight and what is happening in the project. - Multiply above by many times and also don't assume people end up on the PMC and add a highly moving community to the mix (which means, important people become inactive and some new blood enters. - If a lot of old timers become inactive without looking for replacements and keeping the PMC in a good size, projects are going to have a hard time, new people don't have a possibility to make new releases (not enough votes) or don't know how to properly create releases, etc ,etc Not saying this is going to happen to MyFaces, just a scenario that is at Jakarta and also happens at smaller projects. So any symptoms of that are going to emerge at MyFaces, my advice is to fix the situation with going TLP for that subproject or making the PMC healthy again. Another problem with umbrella projects is that the board is not aware of any problems, dead code, etc, unless the chair or community writes that in the board report. So in fact you are (unintentionally) hiding possible problems. Hence the huge size of most Jakarta board reports to prevent hiding. Mvgr, Martin
