You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by vg...@apache.org on 2003/12/10 16:55:08 UTC

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

vgritsenko    2003/12/10 07:55:08

  Modified:    src/java/org/apache/cocoon/components/source/impl
                        SitemapSource.java
  Log:
  some cleanup
  
  Revision  Changes    Path
  1.15      +11 -12    cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/SitemapSource.java
  
  Index: SitemapSource.java
  ===================================================================
  RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/source/impl/SitemapSource.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- SitemapSource.java	29 Oct 2003 14:45:53 -0000	1.14
  +++ SitemapSource.java	10 Dec 2003 15:55:08 -0000	1.15
  @@ -284,7 +284,7 @@
        * Return an <code>InputStream</code> object to read from the source.
        */
       public InputStream getInputStream()
  -      throws IOException, SourceException {
  +    throws IOException, SourceException {
   
           if (this.needsRefresh) {
               this.refresh();
  @@ -305,7 +305,6 @@
                                                       this.manager,
                                                       this.pipelineProcessor);
               try {
  -                
                   this.processingPipeline.process(this.environment);
               } finally {
                   CocoonComponentManager.leaveEnvironment();
  @@ -368,8 +367,8 @@
        * and content length.
        */
       public void refresh() {
  -        this.reset();
  -        this.init();
  +        reset();
  +        init();
       }
   
       /**
  @@ -437,7 +436,7 @@
           throws SAXException
       {
           if (this.needsRefresh) {
  -            this.refresh();
  +            refresh();
           }
           if (this.exception != null) {
               throw this.exception;
  @@ -481,7 +480,9 @@
        * Reset everything
        */
       private void reset() {
  -        if (this.processingPipeline != null) this.processingPipeline.release();
  +        if (this.processingPipeline != null) {
  +            this.processingPipeline.release();
  +        }
           if (this.processKey != null) {
               CocoonComponentManager.endProcessing(this.environment, this.processKey);
               this.processKey = null;
  @@ -503,9 +504,9 @@
        * Recyclable
        */
       public void recycle() {
  -        this.reset();
  -        if ( this.sourceResolver != null ) {
  -            this.manager.release( this.sourceResolver );
  +        reset();
  +        if (this.sourceResolver != null) {
  +            this.manager.release(this.sourceResolver);
           }
       }
   
  @@ -535,6 +536,4 @@
       public Iterator getParameterNames() {
           return java.util.Collections.EMPTY_LIST.iterator();
       }
  -
  -
   }
  
  
  

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.12.2003 22:56, Vadim Gritsenko wrote:

>>>> Why do you make these changes? A long time ago, we decided  that
>>>> this.method()
>>>> is more readable and we want to use that :)
>>>
>>> Is it? Sorry I might have missed that. It just looks so silly (there 
>>> is no notion of local methods - so you can't mistake it for local 
>>> method) ;-)
>>
>> You can differ static from non-static methods.
> 
> No, you can't. Example: this.ROLE will compile just fine.

Eh? I don't understand. Of course there is no compiler error, but where 
is the problem using this.method() for instance methods and method() for 
class methods. Isn't this exactly the same as for fields (though there 
are additionally the local variables)? Furthermore using this.method() 
for class methods gives a compiler warning "should not be accessed in a 
static way" or similar.

> BTW, you can see this in my today's commit, log: static access.

Yes, saw it - and I had to search a long time for the difference ;-)

Joerg


Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Vadim Gritsenko <va...@verizon.net>.
Joerg Heinicke wrote:

> On 10.12.2003 18:11, Vadim Gritsenko wrote:
>
>>>>  -        this.reset();
>>>>  -        this.init();
>>>>  +        reset();
>>>>  +        init();
>>>
>>>
>>>
>>> Why do you make these changes? A long time ago, we decided  that
>>> this.method()
>>> is more readable and we want to use that :)
>>>  
>>>
>>
>> Is it? Sorry I might have missed that. It just looks so silly (there 
>> is no notion of local methods - so you can't mistake it for local 
>> method) ;-)
>
>
> You can differ static from non-static methods.


No, you can't. Example: this.ROLE will compile just fine.

BTW, you can see this in my today's commit, log: static access.

Vadim



Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.12.2003 18:11, Vadim Gritsenko wrote:

>>>  -        this.reset();
>>>  -        this.init();
>>>  +        reset();
>>>  +        init();
>>
>>
>> Why do you make these changes? A long time ago, we decided  that
>> this.method()
>> is more readable and we want to use that :)
>>  
>>
> 
> Is it? Sorry I might have missed that. It just looks so silly (there is 
> no notion of local methods - so you can't mistake it for local method) ;-)

You can differ static from non-static methods.

Joerg


Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:

>Vadim Gritsenko wrote:
>  
>
>>  -        this.reset();
>>  -        this.init();
>>  +        reset();
>>  +        init();
>>    
>>
>
>Why do you make these changes? A long time ago, we decided  that
>this.method()
>is more readable and we want to use that :)
>  
>

Is it? Sorry I might have missed that. It just looks so silly (there is 
no notion of local methods - so you can't mistake it for local method) ;-)


>No, actually I prefer this.method() as well, but don't mind if someone
>writes
>only method(). But I think changing this back and forth is not a good idea.
>  
>

Ok

Vadim



Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Giacomo Pati <gi...@apache.org>.
Christian Haul schrieb:

> Giacomo Pati wrote:
> 
>>
>> Carsten Ziegeler wrote:
>>
>>> Vadim Gritsenko wrote:
>>>
>>>>  -        this.reset();
>>>>  -        this.init();
>>>>  +        reset();
>>>>  +        init();
>>>
>>>
> 
>> It make sense for member variables but there I'd like to add a prefix 
>> like m_ which cannot be forgotten (as like the 'this.' prefix) and 
>> thus clearly indicates what kind of variable it is (but that is 
>> personal preference, I know ;-)
> 
> 
>>> No, actually I prefer this.method() as well, but don't mind if someone
>>> writes
>>> only method(). But I think changing this back and forth is not a good 
>>> idea.
> 
> 
> Personally, I prefer the this.reset() approach to m_reset(). But at the
> end of the day I second Carsten to not regulate this but please don't
> change back and forth.

I wasn't taking about method prefixes but memeber variables. I don't 
think method prefixing makes much sense (explicit 'super.' is ok).

-- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com



Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Giacomo Pati wrote:
> 
> Carsten Ziegeler wrote:
> 
>> Vadim Gritsenko wrote:
>>
>>>  -        this.reset();
>>>  -        this.init();
>>>  +        reset();
>>>  +        init();
>>

> It make sense for member variables but there I'd like to add a prefix 
> like m_ which cannot be forgotten (as like the 'this.' prefix) and thus 
> clearly indicates what kind of variable it is (but that is personal 
> preference, I know ;-)

>> No, actually I prefer this.method() as well, but don't mind if someone
>> writes
>> only method(). But I think changing this back and forth is not a good 
>> idea.

Personally, I prefer the this.reset() approach to m_reset(). But at the
end of the day I second Carsten to not regulate this but please don't
change back and forth.

	Chris.

Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Timothy Larson <ti...@yahoo.com>.
--- Giacomo Pati <gi...@otego.com> wrote:
> It make sense for member variables but there I'd like to add a prefix 
> like m_ which cannot be forgotten (as like the 'this.' prefix) and thus 
> clearly indicates what kind of variable it is (but that is personal 
> preference, I know ;-)

I often find myself doing the inverse of this by prefixing 'p_'
to the parameters and leaving the member variable names alone.
For my coding habits this gives a greater reduction to the
incidence of errors.

--Tim Larson


__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

RE: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
>
> Carsten Ziegeler wrote:
> > Vadim Gritsenko wrote:
> >
> >>  -        this.reset();
> >>  -        this.init();
> >>  +        reset();
> >>  +        init();
> >
> >
> > Why do you make these changes? A long time ago, we decided  that
> > this.method()
> > is more readable and we want to use that :)
>
> More readable? There is no semantic difference between this.method() and
> method(). Actually I find it silly to add the 'this.' to a method call.
>
If you write method(), you don't know if you call a static method or not.
If you write this.method(), at least the compiler gives you a warning
*if* you call a static method. So if you use it wisely, you see what's
going on.

> It make sense for member variables but there I'd like to add a prefix
> like m_ which cannot be forgotten (as like the 'this.' prefix) and thus
> clearly indicates what kind of variable it is (but that is personal
> preference, I know ;-)
>
:) Please, everything, but not adding these prefixes like 'm_'.

So, in the end, we see here why we shouldn't have strikt coding conventions,
the opinions differ widely :)

Carsten


Re: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Giacomo Pati <gi...@otego.com>.

Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
> 
>>  -        this.reset();
>>  -        this.init();
>>  +        reset();
>>  +        init();
> 
> 
> Why do you make these changes? A long time ago, we decided  that
> this.method()
> is more readable and we want to use that :)

More readable? There is no semantic difference between this.method() and 
method(). Actually I find it silly to add the 'this.' to a method call.

It make sense for member variables but there I'd like to add a prefix 
like m_ which cannot be forgotten (as like the 'this.' prefix) and thus 
clearly indicates what kind of variable it is (but that is personal 
preference, I know ;-)

Giacomo

> No, actually I prefer this.method() as well, but don't mind if someone
> writes
> only method(). But I think changing this back and forth is not a good idea.
> 
> Carsten
> 

-- 
Otego AG                                  Tel:   +41 (0)1  240 00 55
Giacomo Pati, CTO                         Mobile:+41 (0)79 262 21 04
Apache Software Foundation Member         Mailto:giacomo@apache.org
Hohlstrasse 216                           Mailto:Giacomo.Pati@otego.com
CH-8004 Zürich                            Web:   http://www.otego.com



RE: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/source/impl SitemapSource.java

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>   -        this.reset();
>   -        this.init();
>   +        reset();
>   +        init();

Why do you make these changes? A long time ago, we decided  that
this.method()
is more readable and we want to use that :)
No, actually I prefer this.method() as well, but don't mind if someone
writes
only method(). But I think changing this back and forth is not a good idea.

Carsten