Re: [VOTE] NON-RESULT (re-vote) XxxUtils constructors

[Stephen Colebourne <sc...@btopenworld.com>]

Well, surprise, surprise we still don't actually have a decision....

I am calling a halt to the current vote, because
1) New options are now being discussed
2) Most of the people who voted in the first vote haven't voted in the
second vote

The results of the legitimate votes that were cast are:
"protected constructor" =>  -1
"deprecated public constructor" => 3

If all options were considered, and views expressed considered as votes
however:
"protected constructor" =>  -2
"deprecated public constructor" => 2
"public" => 1
"public final" => 3
"bean wrappers" => 2

To declare any _result_ would thus be unreasonable.

IMO however I would suggest that
- protected is being discounted
- support for a positive response to Velocity is growing (ie. something
public)

I will have one more go at this. But not yet. Paul's "public final" option
strikes me as being a compromise that I think 90% would support, either +1
or +0. Unless the discussion changes markedly, the next vote will probably
offer that as the only choice. (Yes or No)

Stephen

----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, August 18, 2002 12:20 PM
Subject: [VOTE] (re-vote) XxxUtils constructors


> The first vote was inconclusive, so I reckon we should have another go...
> ([collections] needs to know for its upcoming release)
>
> Background
> - Some tools, like Velocity, need an instance of static utility classes to
> work with, and thus a public constructor
> - No acceptable workaround for Velocity has been found
> - The current commons standard is private
> - This impacts [collections], [lang] and [io]
> - Some of the [collections] classes already have public constructors
> - Sun's static utility classes have a private constructor
>
> Votes (aimed to get a result!)
> The most popular choices from the first round are on offer.
> (private is implicit as it represents no change - to support private
vote -1
> / 0)
> There are TWO votes, decide on BOTH.
> (+0 and -0 are equivalent in the counting process, so I've merged them)
>
> "use protected constructors for static utility classes"
> [  ] +1   I agree
> [  ]  0   I don't like it, but could live with it
> [  ] -1   I disagree
>
> "use deprecated public constructors for static utility classes"
> [  ] +1   I agree
> [  ]  0   I don't like it, but could live with it
> [  ] -1   I disagree
>
> To pass, a vote needs a total of +1 or greater.
> If neither vote passes, private remains the choice.
> If one vote passes, that becomes the new standard.
> If both votes pass, the one with the most support is carried.
> If they have equal support, the most open - deprecated public is chosen.
>
> Stephen
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VOTE] NON-RESULT (re-vote) XxxUtils constructors

[Daniel Rall <dl...@finemaltcoding.com>]

"Geir Magnusson Jr." <ge...@adeptra.com> writes:

> On 8/19/02 7:58 PM, "Stephen Colebourne" <sc...@btopenworld.com>
> wrote:
> 
> > I will have one more go at this. But not yet. Paul's "public final" option
> > strikes me as being a compromise that I think 90% would support, either +1
> > or +0. Unless the discussion changes markedly, the next vote will probably
> > offer that as the only choice. (Yes or No)
> 
>  public final tends to piss people off.  See java.lang.Class and
> java.lang.String and org.webmacro.*

I stopped using WebMacro and helped define Velocity because everything
in WebMacro was final, and nothing was pluggable.  I prefer not to
repeat the mistakes of the past.
-- 

Daniel Rall <dl...@finemaltcoding.com>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [VOTE] NON-RESULT (re-vote) XxxUtils constructors

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 8/19/02 7:58 PM, "Stephen Colebourne" <sc...@btopenworld.com>
wrote:

> Well, surprise, surprise we still don't actually have a decision....
> 
> I am calling a halt to the current vote, because
> 1) New options are now being discussed
> 2) Most of the people who voted in the first vote haven't voted in the
> second vote
> 
> The results of the legitimate votes that were cast are:
> "protected constructor" =>  -1
> "deprecated public constructor" => 3
> 
> If all options were considered, and views expressed considered as votes
> however:
> "protected constructor" =>  -2
> "deprecated public constructor" => 2
> "public" => 1
> "public final" => 3
> "bean wrappers" => 2
> 
> To declare any _result_ would thus be unreasonable.
> 
> IMO however I would suggest that
> - protected is being discounted
> - support for a positive response to Velocity is growing (ie. something
> public)

LOL.  Could we stop saying it's due to Velocity?  You would have the same
issue in anything that expects bean-ish lifecycle behavior of the components
it uses.

> 
> I will have one more go at this. But not yet. Paul's "public final" option
> strikes me as being a compromise that I think 90% would support, either +1
> or +0. Unless the discussion changes markedly, the next vote will probably
> offer that as the only choice. (Yes or No)

 public final tends to piss people off.  See java.lang.Class and
java.lang.String and org.webmacro.*


-- 
Geir Magnusson Jr. 
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>