11:29
À : discuss@restlet.tigris.org
Objet : Re: XmlRepresentation.internalEval
I don't suppose we have any Eclipse developers on the list taking notes?
On Wed, Oct 15, 2008 at 3:26 AM, Richard Hoberman
<[EMAIL PROTECTED]> wrote:
Tim Peierls wrote:
> It's not a huge deal, bu
I don't suppose we have any Eclipse developers on the list taking notes?
On Wed, Oct 15, 2008 at 3:26 AM, Richard Hoberman <
[EMAIL PROTECTED]> wrote:
> Tim Peierls wrote:
> > It's not a huge deal, but superfluous final keywords are clutter that
> > distract from the places where final is being u
Tim Peierls wrote:
> It's not a huge deal, but superfluous final keywords are clutter that
> distract from the places where final is being used meaningfully. I
> think it's worth cleaning this up incrementally in Restlet.
This would do it:
perl -pie 's/final (?=[a-zA-Z]*Exception)//g' `find . -na
It's not a huge deal, but superfluous final keywords are clutter that
distract from the places where final is being used meaningfully. I think
it's worth cleaning this up incrementally in Restlet.
--tim
On Tue, Oct 14, 2008 at 4:28 PM, Rob Heittman <[EMAIL PROTECTED]>wrote:
> A bit of troglodyti
A bit of troglodytic practicality: I can easily tell Eclipse to stick
"final" wherever it possibly can, but not (to my knowledge) selectively omit
cases like catch blocks. So it makes code that looks like this. I agree
it's kind of dumb here, specifically, but the general practice of allowing
Ecl
I'm doing some reading and have found the following links useful:
1. Link to a free chapter on the final keyword in Robert Simmons
'Hardcore Java' (O'Reilly) together with a useful summary.
http://hoskinator.blogspot.com/2006/04/hardcore-java-final-story.html
2. Brian Goetz comments on the 'fina
--
> *De :* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *De la part de* Tim
> Peierls
> *Envoyé :* mardi 14 octobre 2008 21:06
> *À :* discuss@restlet.tigris.org
> *Cc :* Jerome Louvel
> *Objet :* Re: XmlRepresentation.internalEval
>
> On Tue, Oct 14, 200
: Jerome Louvel
Objet : Re: XmlRepresentation.internalEval
On Tue, Oct 14, 2008 at 2:41 PM, Jerome Louvel <[EMAIL PROTECTED]>
wrote:
For the 'final' keyword usage, it might save a bit of memory at most. No big
gain here I suspect.
How would memory be saved? Are there really compilers
On Tue, Oct 14, 2008 at 2:41 PM, Jerome Louvel <[EMAIL PROTECTED]>wrote:
> For the 'final' keyword usage, it might save a bit of memory at most. No
> big gain here I suspect.
How would memory be saved? Are there really compilers that generate
different bytecode depending on the presence of the f
-Message d'origine-
De : Richard Hoberman [mailto:[EMAIL PROTECTED]
Envoyé : lundi 13 octobre 2008 12:18
À : discuss@restlet.tigris.org
Objet : XmlRepresentation.internalEval
Hi
Here is a snippet of code from a failing test case:
1 DomRepresentation results = response.getEntityAsDom
t most. No big
gain here I suspect.
Best regards,
Jerome
-Message d'origine-
De : Jerome Louvel
Envoyé : mardi 14 octobre 2008 20:37
À : discuss@restlet.tigris.org
Objet : RE: XmlRepresentation.internalEval
Hi Richard,
Thanks for the report. Your suggestion makes sense, so now
Hi
Here is a snippet of code from a failing test case:
1 DomRepresentation results = response.getEntityAsDom();
2 System.out.println(response.getEntityAsForm()); // temporary output
while writing test
3 NodeSet nodes = results.getNodes("/a/b/c");
4 Assert.assertNotNull(nodes); // fails
12 matches
Mail list logo
