You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2003/07/26 20:52:52 UTC

[lang] StringEscapeUtils method names

We currently have names such as
escapeHtml
escapeXml

I believe that the Sun guidelines are
escapeHTML
escapeXML

etc.

Should we change them?

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [lang] StringEscapeUtils method names

Posted by Henri Yandell <ba...@generationjava.com>.

On Sat, 26 Jul 2003, Stephen Colebourne wrote:

> We currently have names such as
> escapeHtml
> escapeXml

+1

> I believe that the Sun guidelines are
> escapeHTML
> escapeXML

Technically. But as others pointed out, Sun fail on these. I used to try
to obey the acronym style, but it's a crap piece of style so I've given up
on that.

Hen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections][patch] LazyList decorator default factory

Posted by Stephen Colebourne <sc...@btopenworld.com>.
Can't remember offhand why there is a null restriction. There is probably
some way to remove it...thus making the class more useful
Stephen

----- Original Message -----
From: "Neil O'Toole" <ne...@users.sourceforge.net>
> Having read the javadoc (for a change ;)), and this line:
>
> > Thus this list is unsuitable for storing null objects
>
> then the patch below is irrelevant. However, if the list is indeed
> unsuitable for null, then LazyList should override the #add methods to
> throw an IllegalArgumentException when the client attempts to add null.
>
> - Neil
>
>
> --- Neil O'Toole <ne...@yahoo.com> wrote:
> > Including the patch this time...
> >
> >
> > --- Neil O'Toole <ne...@yahoo.com> wrote:
> > >
> > > In general, decorators should strive to provide an instantiation
> > > method
> > > of the form #decorate( decoratee ) whenever it is possible to
> > provide
> > > sensible defaults for the behaviour of the decorator. The attached
> > > patch adds a method LazyList#decorate( List ) which uses the null
> > > factory. This is a very common case, and it's much neater to do
> > >
> > >  List lazy = LazyList.decorate( list );
> > >
> > > than
> > >
> > >  List lazy = LazyList.decorate( list, FactoryUtils.nullFactory() );
> > >
> > > In fact, I'd written my own null factory before I discovered the
> > one
> > > in
> > > FactoryUtils ;), so this certainly lowers the usage-barrier for
> > > LazyList.
> > >
> > > * It should be trivial to add equivalent support for LazyMap etc..
> > >
> > > Neil
> > >
> > >
> > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > commons-dev-help@jakarta.apache.org
> > >
> > > Index: LazyList.java
> > ===================================================================
> > RCS file:
> >
>
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/coll
ections/decorators/LazyList.java,v
> > retrieving revision 1.2
> > diff -u -r1.2 LazyList.java
> > --- LazyList.java 7 May 2003 11:20:21 -0000 1.2
> > +++ LazyList.java 26 Jul 2003 22:14:41 -0000
> > @@ -60,6 +60,7 @@
> >  import java.util.List;
> >
> >  import org.apache.commons.collections.Factory;
> > +import org.apache.commons.collections.FactoryUtils;
> >
> >  /**
> >   * <code>LazyList</code> decorates another <code>List</code>
> > @@ -100,6 +101,18 @@
> >
> >      /** The factory to use to lazily instantiate the objects */
> >      protected final Factory factory;
> > +
> > + /**
> > + * Factory method to create a lazily instantiating list. Newly
> > + * created elements will be filled with nulls.
> > + *
> > + * @param list the list to decorate, must not be null
> > + * @throws IllegalArgumentException if list is null
> > + */
> > + public static List decorate(List list) {
> > + return new LazyList(list, FactoryUtils.nullFactory());
> > + }
> > +
> >
> >      /**
> >       * Factory method to create a lazily instantiating list.
> >
> > >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections][patch] LazyList decorator default factory

Posted by Neil O'Toole <ne...@users.sourceforge.net>.
Having read the javadoc (for a change ;)), and this line:

> Thus this list is unsuitable for storing null objects

then the patch below is irrelevant. However, if the list is indeed
unsuitable for null, then LazyList should override the #add methods to
throw an IllegalArgumentException when the client attempts to add null.

- Neil


--- Neil O'Toole <ne...@yahoo.com> wrote:
> Including the patch this time...
> 
> 
> --- Neil O'Toole <ne...@yahoo.com> wrote:
> > 
> > In general, decorators should strive to provide an instantiation
> > method
> > of the form #decorate( decoratee ) whenever it is possible to
> provide
> > sensible defaults for the behaviour of the decorator. The attached
> > patch adds a method LazyList#decorate( List ) which uses the null
> > factory. This is a very common case, and it's much neater to do
> > 
> >  List lazy = LazyList.decorate( list );
> > 
> > than
> > 
> >  List lazy = LazyList.decorate( list, FactoryUtils.nullFactory() );
> > 
> > In fact, I'd written my own null factory before I discovered the
> one
> > in
> > FactoryUtils ;), so this certainly lowers the usage-barrier for
> > LazyList.
> > 
> > * It should be trivial to add equivalent support for LazyMap etc..
> > 
> > Neil
> > 
> > 
> > 
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> commons-dev-help@jakarta.apache.org
> > 
> > Index: LazyList.java
> ===================================================================
> RCS file:
>
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/collections/decorators/LazyList.java,v
> retrieving revision 1.2
> diff -u -r1.2 LazyList.java
> --- LazyList.java	7 May 2003 11:20:21 -0000	1.2
> +++ LazyList.java	26 Jul 2003 22:14:41 -0000
> @@ -60,6 +60,7 @@
>  import java.util.List;
>  
>  import org.apache.commons.collections.Factory;
> +import org.apache.commons.collections.FactoryUtils;
>  
>  /**
>   * <code>LazyList</code> decorates another <code>List</code>
> @@ -100,6 +101,18 @@
>      
>      /** The factory to use to lazily instantiate the objects */
>      protected final Factory factory;
> +
> +	/**
> +	 * Factory method to create a lazily instantiating list. Newly
> +	 * created elements will be filled with nulls.
> +	 * 
> +	 * @param list the list to decorate, must not be null
> +	 * @throws IllegalArgumentException if list is null
> +	 */
> +	public static List decorate(List list) {
> +		return new LazyList(list, FactoryUtils.nullFactory());
> +	}
> +
>  
>      /**
>       * Factory method to create a lazily instantiating list.
> 
> >
---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [collections][patch] LazyList decorator default factory

Posted by Neil O'Toole <ne...@yahoo.com>.
Including the patch this time...


--- Neil O'Toole <ne...@yahoo.com> wrote:
> 
> In general, decorators should strive to provide an instantiation
> method
> of the form #decorate( decoratee ) whenever it is possible to provide
> sensible defaults for the behaviour of the decorator. The attached
> patch adds a method LazyList#decorate( List ) which uses the null
> factory. This is a very common case, and it's much neater to do
> 
>  List lazy = LazyList.decorate( list );
> 
> than
> 
>  List lazy = LazyList.decorate( list, FactoryUtils.nullFactory() );
> 
> In fact, I'd written my own null factory before I discovered the one
> in
> FactoryUtils ;), so this certainly lowers the usage-barrier for
> LazyList.
> 
> * It should be trivial to add equivalent support for LazyMap etc..
> 
> Neil
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

[collections][patch] LazyList decorator default factory

Posted by Neil O'Toole <ne...@yahoo.com>.
In general, decorators should strive to provide an instantiation method
of the form #decorate( decoratee ) whenever it is possible to provide
sensible defaults for the behaviour of the decorator. The attached
patch adds a method LazyList#decorate( List ) which uses the null
factory. This is a very common case, and it's much neater to do

 List lazy = LazyList.decorate( list );

than

 List lazy = LazyList.decorate( list, FactoryUtils.nullFactory() );

In fact, I'd written my own null factory before I discovered the one in
FactoryUtils ;), so this certainly lowers the usage-barrier for
LazyList.

* It should be trivial to add equivalent support for LazyMap etc..

Neil




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org