You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2003/10/13 06:54:49 UTC
[collections] Should LazyMap use a Transformer instead of a Factory?
When a LazyMap creates a value on demand, it seems natural to use a
Transformer that takes the key as input. In many (most?) cases, the key
might be ignored, but it makes sense to make it available. LazyMap does
have a protected Transformer member that it uses to create values, but
the decorate method takes a Factory (which is converted to an
effectively argumentless Transformer using
TransformerUtils.asTransformer(Factory)). Why not have decorate take a
Transformer? This would seem to be more flexible. Am I missing something?
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Should LazyMap use a Transformer instead of a Factory?
Posted by Phil Steitz <st...@yahoo.com>.
Sorry. Yes, it was me who was dreaming -- I misread the code. The
functionality that I was looking for is there.
Phil
--- Stephen Colebourne <sc...@btopenworld.com> wrote:
> Unless I'm dreaming, the Transformer code is in there...
> Stephen
>
> ----- Original Message -----
> From: "Phil Steitz" <ph...@steitz.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Monday, October 13, 2003 5:54 AM
> Subject: [collections] Should LazyMap use a Transformer instead of a
> Factory?
>
>
> > When a LazyMap creates a value on demand, it seems natural to use a
> > Transformer that takes the key as input. In many (most?) cases, the key
> > might be ignored, but it makes sense to make it available. LazyMap does
> > have a protected Transformer member that it uses to create values, but
> > the decorate method takes a Factory (which is converted to an
> > effectively argumentless Transformer using
> > TransformerUtils.asTransformer(Factory)). Why not have decorate take a
> > Transformer? This would seem to be more flexible. Am I missing
> something?
> >
> > Phil
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Should LazyMap use a Transformer instead of a Factory?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Unless I'm dreaming, the Transformer code is in there...
Stephen
----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, October 13, 2003 5:54 AM
Subject: [collections] Should LazyMap use a Transformer instead of a
Factory?
> When a LazyMap creates a value on demand, it seems natural to use a
> Transformer that takes the key as input. In many (most?) cases, the key
> might be ignored, but it makes sense to make it available. LazyMap does
> have a protected Transformer member that it uses to create values, but
> the decorate method takes a Factory (which is converted to an
> effectively argumentless Transformer using
> TransformerUtils.asTransformer(Factory)). Why not have decorate take a
> Transformer? This would seem to be more flexible. Am I missing something?
>
> Phil
>
>
> ---------------------------------------------------------------------
> 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