[lang] Heading towards a Lang 2.2 release?

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[lang] Heading towards a Lang 2.2 release?

Henri Yandell
Is anyone opposed to my starting to put together an rc1 distribution
for Lang 2.2?

The current state of play can be seen at:

http://issues.apache.org/jira/browse/LANG

There is one issue left in 2.2; a bug that sometimes passes tests and
sometimes fails - regardless of which, I'm not sure how to fix it even
when I do figure out how to make it repeatedly fail. I suspect I have
to sit and play with my system clock. I'm tempted to push it back to
2.3.

The next release, 2.3, has 9 issues in. Enum ones, a few new methods
for various XxxUtils and some that I've pushed back from 2.2.

The 3.0 release has a dozen more new methods and cleanup items.

So I'm thinking - push LANG-59 back to 2.3 and go ahead and release 2.2.

Any thoughts? Anyone got any ideas on LANG-59 solution-wise? Anyone
know of any half-finished code in there at the moment?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[lang] VariableFormatter - pre 2.2

Stephen Colebourne
Henri Yandell wrote:
> Anyone know of any half-finished code in there at the moment?

I think I'm on record for saying that the VariableFormatter class
doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...

At a minimum, I'd like to see MapVariableResolver packge scoped.

However, I thnk I'd rather see VariableResolver changed to be a more
general StrLookup class rather like StrMatcher. That way it could be
used equally as well independent of VariableFormatter.

public class StrLookup {
   String lookup(String key);

   // package scoped implementation for Map
}

You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
or perhaps ones that accessed a List of strings by index.

The key point is that this shouldn't be limited to just
VariableFormatter in the same way that StrMatcher isn't limited to
StrTokenizer. Separation of Concerns.

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Oliver Heger-3
Stephen Colebourne wrote:

> Henri Yandell wrote:
>> Anyone know of any half-finished code in there at the moment?
>
> I think I'm on record for saying that the VariableFormatter class
> doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
>
> At a minimum, I'd like to see MapVariableResolver packge scoped.
>
> However, I thnk I'd rather see VariableResolver changed to be a more
> general StrLookup class rather like StrMatcher. That way it could be
> used equally as well independent of VariableFormatter.
>
> public class StrLookup {
>   String lookup(String key);
>
>   // package scoped implementation for Map
> }
>
> You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
> or perhaps ones that accessed a List of strings by index.
>
> The key point is that this shouldn't be limited to just
> VariableFormatter in the same way that StrMatcher isn't limited to
> StrTokenizer. Separation of Concerns.
>
Fine with me, but could the return value of lookup be Object instead of
String? Especially if you want to use this interface in other areas, you
might need more freedom. If only String processing needs to be
performed, the returned Object can be transformed to a String by calling
toString().

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] Heading towards a Lang 2.2 release?

Gary Gregory
In reply to this post by Henri Yandell
Hi All:

> -----Original Message-----
> From: Henri Yandell [mailto:[hidden email]]
> Sent: Monday, July 03, 2006 10:03 PM
> To: Jakarta Commons Developers List
> Subject: [lang] Heading towards a Lang 2.2 release?
>
> Is anyone opposed to my starting to put together an rc1 distribution
> for Lang 2.2?

+1!

>
> The current state of play can be seen at:
>
> http://issues.apache.org/jira/browse/LANG
>
> There is one issue left in 2.2; a bug that sometimes passes tests and
> sometimes fails - regardless of which, I'm not sure how to fix it even
> when I do figure out how to make it repeatedly fail. I suspect I have
> to sit and play with my system clock. I'm tempted to push it back to
> 2.3.

Can the APIs be parameterized such that we can pass in various system
times during tests?

Gary


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[lang] JRE level?

Gary Gregory
In reply to this post by Oliver Heger-3
Hello All:

Based on the project.properties file entry:

maven.compile.source = 1.3

I assume that we are making Java 1.3 the requirement.

We therefore should not have Java 1.4 dependencies:

Severity and Description Path Resource Location
Creation Time Id
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 135 1151797976890 13807342
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 136 1151797976890 13807346
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 169 1151797976890 13807374
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 269 1151797976890 13807406
The method getCause() is undefined for the type Throwable Apache
Jakarta Commons
trunks-proper/lang/src/test/org/apache/commons/lang/exception
ExceptionUtilsTestCase.java line 316 1151797976890 13807407

Or am I missing something?

Thanks,
Gary

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] VariableFormatter - pre 2.2

Gary Gregory
In reply to this post by Stephen Colebourne
Hello All:

> At a minimum, I'd like to see MapVariableResolver packge scoped.

Looking at the message thread:

http://www.mail-archive.com/commons-dev@.../msg78697.html

It seems that another proposal being discussed back in April was to make
some classes /easier/ to reuse and extend for the more advanced users by
making them come out of inner, which would also mean keeping them
public.

> However, I thnk I'd rather see VariableResolver changed to be a more
> general StrLookup class rather like StrMatcher. That way it could be
> used equally as well independent of VariableFormatter.

The challenge to me here is that I've heard some folks says they do not
want [lang] to become too framework-like. I am wondering if making
VariableResolver more generic would go in that direction. The nice thing
I see about the way it is now is that the solution is on making the
variable resolver pluggable and nothing more. Which is a draw back if
that interface is really /that great/.

FWIW, I am pretty happy with using the VariableFormatter class as is and
plan on doing so (as soon as my work schedule allows.)

Gary

> -----Original Message-----
> From: Stephen Colebourne [mailto:[hidden email]]
> Sent: Wednesday, July 05, 2006 5:07 PM
> To: Jakarta Commons Developers List
> Subject: [lang] VariableFormatter - pre 2.2
>
> Henri Yandell wrote:
> > Anyone know of any half-finished code in there at the moment?
>
> I think I'm on record for saying that the VariableFormatter class
> doesn't quite fit as is IMHO. But I've not spelt out why, so here
goes...

>
> At a minimum, I'd like to see MapVariableResolver packge scoped.
>
> However, I thnk I'd rather see VariableResolver changed to be a more
> general StrLookup class rather like StrMatcher. That way it could be
> used equally as well independent of VariableFormatter.
>
> public class StrLookup {
>    String lookup(String key);
>
>    // package scoped implementation for Map
> }
>
> You could envisage other (non [lang]) accessors such as OGNL, EL,
XPath

> or perhaps ones that accessed a List of strings by index.
>
> The key point is that this shouldn't be limited to just
> VariableFormatter in the same way that StrMatcher isn't limited to
> StrTokenizer. Separation of Concerns.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] JRE level?

Stephen Colebourne
In reply to this post by Gary Gregory
[lang] should be JDK1.2 compliant, although I tend to think of it as
1.3+ with 1.2 at users risk.

Stephen

Gary Gregory wrote:

> Hello All:
>
> Based on the project.properties file entry:
>
> maven.compile.source = 1.3
>
> I assume that we are making Java 1.3 the requirement.
>
> We therefore should not have Java 1.4 dependencies:
>
> Severity and Description Path Resource Location
> Creation Time Id
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 135 1151797976890 13807342
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 136 1151797976890 13807346
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 169 1151797976890 13807374
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 269 1151797976890 13807406
> The method getCause() is undefined for the type Throwable Apache
> Jakarta Commons
> trunks-proper/lang/src/test/org/apache/commons/lang/exception
> ExceptionUtilsTestCase.java line 316 1151797976890 13807407
>
> Or am I missing something?
>
> Thanks,
> Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Stephen Colebourne
In reply to this post by Gary Gregory
Gary Gregory wrote:
>>At a minimum, I'd like to see MapVariableResolver packge scoped.
>
> Looking at the message thread:
> http://www.mail-archive.com/commons-dev@.../msg78697.html
> It seems that another proposal being discussed back in April was to make
> some classes /easier/ to reuse and extend for the more advanced users by
> making them come out of inner, which would also mean keeping them
> public.

The problem here is that once we publish the API thats it, we can't
unpublish it. MapVariableResolver seems like an internal class that we
create for our own needs. All the constructors allow for a Map to be
passed in, so the users of MapVariableResolver will be very much edge
case users.


>>However, I thnk I'd rather see VariableResolver changed to be a more
>>general StrLookup class rather like StrMatcher. That way it could be
>>used equally as well independent of VariableFormatter.

Gary Gregory wrote:
> The challenge to me here is that I've heard some folks says they do not
> want [lang] to become too framework-like. I am wondering if making
> VariableResolver more generic would go in that direction. The nice thing
> I see about the way it is now is that the solution is on making the
> variable resolver pluggable and nothing more. Which is a draw back if
> that interface is really /that great/.

The question is whether we can see a [lang] use case for using StrLookup
other than in VariableFormatter.


Oliver Heger wrote:
 > Fine with me, but could the return value of lookup be Object instead
 > of String? Especially if you want to use this interface in other
  areas, you might need more freedom. If only String processing needs
 > to be performed, the returned Object can be transformed to a String by
 > calling toString().

But what kind of object are you expectng to be returned here (other than
a String)?

A similar question applies to the replaceObject() method which appears
to have very odd semantics as you can't rely on the return value being
of any specific type. What Objects are you expecting to work with?

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] JRE level?

Henri Yandell
In reply to this post by Stephen Colebourne
Grumble, grumble, Maven -> 1.4+, grumble, grumble, OS X -> no 1.2.x,
grumble, grumble, grumble.

How did you catch this by the way Gary?

Hen

On 7/6/06, Stephen Colebourne <[hidden email]> wrote:

> [lang] should be JDK1.2 compliant, although I tend to think of it as
> 1.3+ with 1.2 at users risk.
>
> Stephen
>
> Gary Gregory wrote:
> > Hello All:
> >
> > Based on the project.properties file entry:
> >
> > maven.compile.source = 1.3
> >
> > I assume that we are making Java 1.3 the requirement.
> >
> > We therefore should not have Java 1.4 dependencies:
> >
> > Severity and Description      Path    Resource        Location
> > Creation Time Id
> > The method getCause() is undefined for the type Throwable     Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java   line 135        1151797976890   13807342
> > The method getCause() is undefined for the type Throwable     Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java   line 136        1151797976890   13807346
> > The method getCause() is undefined for the type Throwable     Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java   line 169        1151797976890   13807374
> > The method getCause() is undefined for the type Throwable     Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java   line 269        1151797976890   13807406
> > The method getCause() is undefined for the type Throwable     Apache
> > Jakarta Commons
> > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > ExceptionUtilsTestCase.java   line 316        1151797976890   13807407
> >
> > Or am I missing something?
> >
> > Thanks,
> > Gary
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] JRE level?

Gary Gregory
I have the Eclipse project that the code lives in on my machine setup
with Java 1.3.1. In Eclipse, you can set a different JRE for each
project or have a project inherit the JRE from the containing workspace.

Gary

> -----Original Message-----
> From: Henri Yandell [mailto:[hidden email]]
> Sent: Friday, July 07, 2006 9:43 AM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] JRE level?
>
> Grumble, grumble, Maven -> 1.4+, grumble, grumble, OS X -> no 1.2.x,
> grumble, grumble, grumble.
>
> How did you catch this by the way Gary?
>
> Hen
>
> On 7/6/06, Stephen Colebourne <[hidden email]> wrote:
> > [lang] should be JDK1.2 compliant, although I tend to think of it as
> > 1.3+ with 1.2 at users risk.
> >
> > Stephen
> >
> > Gary Gregory wrote:
> > > Hello All:
> > >
> > > Based on the project.properties file entry:
> > >
> > > maven.compile.source = 1.3
> > >
> > > I assume that we are making Java 1.3 the requirement.
> > >
> > > We therefore should not have Java 1.4 dependencies:
> > >
> > > Severity and Description      Path    Resource        Location
> > > Creation Time Id
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java   line 135        1151797976890
13807342
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java   line 136        1151797976890
13807346
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java   line 169        1151797976890
13807374
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java   line 269        1151797976890
13807406
> > > The method getCause() is undefined for the type Throwable
Apache
> > > Jakarta Commons
> > > trunks-proper/lang/src/test/org/apache/commons/lang/exception
> > > ExceptionUtilsTestCase.java   line 316        1151797976890
13807407
> > >
> > > Or am I missing something?
> > >
> > > Thanks,
> > > Gary
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail:
[hidden email]
> > >
> > >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Oliver Heger-3
In reply to this post by Stephen Colebourne
Stephen Colebourne wrote:
<snip/>

>
> Oliver Heger wrote:
>  > Fine with me, but could the return value of lookup be Object instead
>  > of String? Especially if you want to use this interface in other
>  areas, you might need more freedom. If only String processing needs
>  > to be performed, the returned Object can be transformed to a String by
>  > calling toString().
>
> But what kind of object are you expectng to be returned here (other than
> a String)?
>
> A similar question applies to the replaceObject() method which appears
> to have very odd semantics as you can't rely on the return value being
> of any specific type. What Objects are you expecting to work with?
>
> Stephen
>
I plan to use the class in [configuration] for variable substitution. A
variable can represent a configuration property, which can have an
arbitrary type.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Henri Yandell
On 7/7/06, Oliver Heger <[hidden email]> wrote:

> Stephen Colebourne wrote:
> <snip/>
>
> >
> > Oliver Heger wrote:
> >  > Fine with me, but could the return value of lookup be Object instead
> >  > of String? Especially if you want to use this interface in other
> >  areas, you might need more freedom. If only String processing needs
> >  > to be performed, the returned Object can be transformed to a String by
> >  > calling toString().
> >
> > But what kind of object are you expectng to be returned here (other than
> > a String)?
> >
> > A similar question applies to the replaceObject() method which appears
> > to have very odd semantics as you can't rely on the return value being
> > of any specific type. What Objects are you expecting to work with?
> >
> > Stephen
> >
> I plan to use the class in [configuration] for variable substitution. A
> variable can represent a configuration property, which can have an
> arbitrary type.

Anything further on this thread? Any sign of consensus?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Henri Yandell
In reply to this post by Stephen Colebourne
This is all that's left in 2.2 before an RC can be built.

On 7/5/06, Stephen Colebourne <[hidden email]> wrote:
> Henri Yandell wrote:
> > Anyone know of any half-finished code in there at the moment?
>
> I think I'm on record for saying that the VariableFormatter class
> doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
>
> At a minimum, I'd like to see MapVariableResolver packge scoped.

Reading the following in the threads, no one seems to be against
making MapVariableResolver package scoped.

Personally I don't think we should have public nested classes,
especially if they're intended for extension. That might just be me
being a dumb user.

VariableResolver is another public nested class (well interface). Any
reason to not have this be package scoped for the 2.2 release as well?

> However, I thnk I'd rather see VariableResolver changed to be a more
> general StrLookup class rather like StrMatcher. That way it could be
> used equally as well independent of VariableFormatter.
>
> public class StrLookup {
>    String lookup(String key);
>
>    // package scoped implementation for Map
> }
>
> You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
> or perhaps ones that accessed a List of strings by index.
>
> The key point is that this shouldn't be limited to just
> VariableFormatter in the same way that StrMatcher isn't limited to
> StrTokenizer. Separation of Concerns.

A 2.3/3.0 subject?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Tom Schindl-3
Henri Yandell schrieb:

> This is all that's left in 2.2 before an RC can be built.
>
> On 7/5/06, Stephen Colebourne <[hidden email]> wrote:
>> Henri Yandell wrote:
>> > Anyone know of any half-finished code in there at the moment?
>>
>> I think I'm on record for saying that the VariableFormatter class
>> doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
>>
>> At a minimum, I'd like to see MapVariableResolver packge scoped.
>
> Reading the following in the threads, no one seems to be against
> making MapVariableResolver package scoped.
>
> Personally I don't think we should have public nested classes,
> especially if they're intended for extension. That might just be me
> being a dumb user.
>
> VariableResolver is another public nested class (well interface). Any
> reason to not have this be package scoped for the 2.2 release as well?
>

Well I don't mind whether the the resolver is made package scoped as
long as I can somehow subclass it (at my own risk) adding the
MessageFormat.format() things.

Tom

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] VariableFormatter - pre 2.2

Gary Gregory
In reply to this post by Henri Yandell
Do you'all think the variable code be simpler to groke/reuse for
customers if there we changed the nested classes into 1st class
citizens? Kinda of a side issue I know...

G

> -----Original Message-----
> From: Henri Yandell [mailto:[hidden email]]
> Sent: Thursday, July 20, 2006 10:55 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] VariableFormatter - pre 2.2
>
> This is all that's left in 2.2 before an RC can be built.
>
> On 7/5/06, Stephen Colebourne <[hidden email]> wrote:
> > Henri Yandell wrote:
> > > Anyone know of any half-finished code in there at the moment?
> >
> > I think I'm on record for saying that the VariableFormatter class
> > doesn't quite fit as is IMHO. But I've not spelt out why, so here
goes...

> >
> > At a minimum, I'd like to see MapVariableResolver packge scoped.
>
> Reading the following in the threads, no one seems to be against
> making MapVariableResolver package scoped.
>
> Personally I don't think we should have public nested classes,
> especially if they're intended for extension. That might just be me
> being a dumb user.
>
> VariableResolver is another public nested class (well interface). Any
> reason to not have this be package scoped for the 2.2 release as well?
>
> > However, I thnk I'd rather see VariableResolver changed to be a more
> > general StrLookup class rather like StrMatcher. That way it could be
> > used equally as well independent of VariableFormatter.
> >
> > public class StrLookup {
> >    String lookup(String key);
> >
> >    // package scoped implementation for Map
> > }
> >
> > You could envisage other (non [lang]) accessors such as OGNL, EL,
XPath

> > or perhaps ones that accessed a List of strings by index.
> >
> > The key point is that this shouldn't be limited to just
> > VariableFormatter in the same way that StrMatcher isn't limited to
> > StrTokenizer. Separation of Concerns.
>
> A 2.3/3.0 subject?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Oliver Heger-3
In reply to this post by Henri Yandell
Henri Yandell wrote:

> This is all that's left in 2.2 before an RC can be built.
>
> On 7/5/06, Stephen Colebourne <[hidden email]> wrote:
>> Henri Yandell wrote:
>> > Anyone know of any half-finished code in there at the moment?
>>
>> I think I'm on record for saying that the VariableFormatter class
>> doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
>>
>> At a minimum, I'd like to see MapVariableResolver packge scoped.
>
> Reading the following in the threads, no one seems to be against
> making MapVariableResolver package scoped.
>
> Personally I don't think we should have public nested classes,
> especially if they're intended for extension. That might just be me
> being a dumb user.
>
> VariableResolver is another public nested class (well interface). Any
> reason to not have this be package scoped for the 2.2 release as well?

If this interface was made package scope, it could not be implemented by
client code. So the option of providing specialized variable resolver
implementations (which I need for my purposes) would be lost. Or am I
missing something?

Oliver

>
>> However, I thnk I'd rather see VariableResolver changed to be a more
>> general StrLookup class rather like StrMatcher. That way it could be
>> used equally as well independent of VariableFormatter.
>>
>> public class StrLookup {
>>    String lookup(String key);
>>
>>    // package scoped implementation for Map
>> }
>>
>> You could envisage other (non [lang]) accessors such as OGNL, EL, XPath
>> or perhaps ones that accessed a List of strings by index.
>>
>> The key point is that this shouldn't be limited to just
>> VariableFormatter in the same way that StrMatcher isn't limited to
>> StrTokenizer. Separation of Concerns.
>
> A 2.3/3.0 subject?
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Henri Yandell
On 7/21/06, Oliver Heger <[hidden email]> wrote:

> Henri Yandell wrote:
> > This is all that's left in 2.2 before an RC can be built.
> >
> > On 7/5/06, Stephen Colebourne <[hidden email]> wrote:
> >> Henri Yandell wrote:
> >> > Anyone know of any half-finished code in there at the moment?
> >>
> >> I think I'm on record for saying that the VariableFormatter class
> >> doesn't quite fit as is IMHO. But I've not spelt out why, so here goes...
> >>
> >> At a minimum, I'd like to see MapVariableResolver packge scoped.
> >
> > Reading the following in the threads, no one seems to be against
> > making MapVariableResolver package scoped.
> >
> > Personally I don't think we should have public nested classes,
> > especially if they're intended for extension. That might just be me
> > being a dumb user.
> >
> > VariableResolver is another public nested class (well interface). Any
> > reason to not have this be package scoped for the 2.2 release as well?
>
> If this interface was made package scope, it could not be implemented by
> client code. So the option of providing specialized variable resolver
> implementations (which I need for my purposes) would be lost. Or am I
> missing something?

I think that was definitely Stephen's aim.

Basically I want to get Lang 2.2 out and have this discussion be a
part of 2.3. Stephen's suggestion allows us to get the basic
VariableFormatter functionality that most people need (I think?) out
there and continue talking about the more powerful aspects for a later
release.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

jodastephen
I have reworked the VariableFormatter class along the lines that I was
thinking. I have committed it as StrSubstitutor so it doesn't clash for
the moment and so it can be easiy reviewed.

This version does not have a separate parser class, but still supports
escaping, and matchers for prefix/suffix (which can now be set by
users). The new class should perform better as a result.

I have removed the edge cases wrt resolving Objects, as they were rather
  ill-defined.

Otherwise, the basic functionality it supported, and the test case is
slightly enlarged. I still want to break out the resolver as a public
abstract class before release.

Opinions

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Stephen Colebourne
In reply to this post by Stephen Colebourne
I have reworked the VariableFormatter class along the lines that I was  thinking. I have committed it as StrSubstitutor so it doesn't clash for  the moment and so it can be easiy reviewed.
 
 This version does not have a separate parser class, but still supports  escaping, and matchers for prefix/suffix (which can now be set by  users). The new class should perform better as a result.
 
 I have removed the edge cases wrt resolving Objects, as they were rather   ill-defined.
 
 Otherwise, the basic functionality it supported, and the test case is  slightly enlarged. I still want to break out the resolver as a public  abstract class before release.
 
 Opinions
 
 Stephen
 
 PS. Having trouble sending mails ATM
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] VariableFormatter - pre 2.2

Henri Yandell
On 7/23/06, Stephen Colebourne <[hidden email]> wrote:
> I have reworked the VariableFormatter class along the lines that I was  thinking. I have committed it as StrSubstitutor so it doesn't clash for  the moment and so it can be easiy reviewed.
>
>  This version does not have a separate parser class, but still supports  escaping, and matchers for prefix/suffix (which can now be set by  users). The new class should perform better as a result.
>
>  I have removed the edge cases wrt resolving Objects, as they were rather   ill-defined.
>
>  Otherwise, the basic functionality it supported, and the test case is  slightly enlarged. I still want to break out the resolver as a public  abstract class before release.
>
>  Opinions

Oliver, Gary, Tom?

Looking to get Lang 2.2 moving out the door and this is the only blocker.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123