I'm okay with layers too. You need to open up the API for querying so that
upper layers can "traverse" the graph.
On Thursday, August 15, 2013, Oliver Heger wrote:
> Am 15.08.2013 15:33, schrieb James Carman:
> > Perhaps you'd have a different method on the "registry" like this:
> >
> > Converte
Am 15.08.2013 15:33, schrieb James Carman:
> Perhaps you'd have a different method on the "registry" like this:
>
> Converter createConverterPath(Class fromType, Class toType);
>
> This way, you're specifically letting the registry know that you're
> okay with it filling in the blanks in between
Perhaps you'd have a different method on the "registry" like this:
Converter createConverterPath(Class fromType, Class toType);
This way, you're specifically letting the registry know that you're
okay with it filling in the blanks in between fromType and toType.
On Thu, Aug 15, 2013 at 9:24 AM,
On Thu, Aug 15, 2013 at 9:09 AM, James Carman wrote:
> You mean if it has a converter from A -> B and B -> C and you ask for
> a conversion from A -> C, it would figure it out? That's and
> interesting idea. I guess you'd need to make sure there is no loss of
> fidelity when doing the conversion
You mean if it has a converter from A -> B and B -> C and you ask for
a conversion from A -> C, it would figure it out? That's and
interesting idea. I guess you'd need to make sure there is no loss of
fidelity when doing the conversions.
On Thu, Aug 15, 2013 at 8:00 AM, Gary Gregory wrote:
> S
Should the framework try to convert transitively?
Gary
On Aug 15, 2013, at 6:56, James Carman wrote:
> I personally think we're over-thinking this thing. Keep it simple, folks:
>
> public interface Converter
> {
> T convert(F from);
> }
>
> You can auto-detect the F/T parameters when a Conver
I personally think we're over-thinking this thing. Keep it simple, folks:
public interface Converter
{
T convert(F from);
}
You can auto-detect the F/T parameters when a Converter is registered.
On Thu, Aug 15, 2013 at 4:42 AM, Jörg Schaible
wrote:
> Hi,
>
> Emmanuel Bourg wrote:
>
>> Le 14/
Hi,
Emmanuel Bourg wrote:
> Le 14/08/2013 17:39, Adrian Crum a écrit :
>
>> Instead of
>>
>> int columnInt = record.getValueAsInt(1);
>>
>> the developer would use
>>
>> Integer columnInt = Util.convertTo(record.getValue(1), Integer.class);
>
> +1 for the static method, that would allow the use
On Wed, Aug 14, 2013 at 4:04 PM, Emmanuel Bourg wrote:
>
> That being said, [convert] could offer several patterns to perform type
> conversion, and the use of proxies could be one of them.
>
>
I know of a project that might be able to help you with those proxies, too! :)
---
The only danger of static methods is that you can't override them.
BeanUtils first suffered from this fate and they then made an instance
version (BeanUtils2). Just said plainly, you can't customize well using
factory classes/methods.
On Wed, Aug 14, 2013 at 3:04 PM, Emmanuel Bourg wrote:
> Le
Le 14/08/2013 17:39, Adrian Crum a écrit :
Instead of
int columnInt = record.getValueAsInt(1);
the developer would use
Integer columnInt = Util.convertTo(record.getValue(1), Integer.class);
+1 for the static method, that would allow the use of a static import
and a very concise syntax like
Am 14.08.2013 17:39, schrieb Adrian Crum:
> I don't think CSV needs anything special to accommodate type conversion.
>
> The pattern I tried to introduce in the Commons Convert "Getting
> Started" section is one that works in any part of an application where
> conversion might be needed. So, inste
Am 14.08.2013 16:54, schrieb Gary Gregory:
> On Tue, Aug 13, 2013 at 4:01 PM, Oliver Heger
> wrote:
>
>> Hi all,
>>
>> recently, there was a discussion about extending the [csv] interface to
>> provide data conversions to different types. If such a use case is to be
>> supported, what would be the
I don't think CSV needs anything special to accommodate type conversion.
The pattern I tried to introduce in the Commons Convert "Getting
Started" section is one that works in any part of an application where
conversion might be needed. So, instead of hard-coding conversions, the
developer cre
On Tue, Aug 13, 2013 at 4:01 PM, Oliver Heger
wrote:
> Hi all,
>
> recently, there was a discussion about extending the [csv] interface to
> provide data conversions to different types. If such a use case is to be
> supported, what would be the best approach to integrate a library like
> [convert]
Hi all,
recently, there was a discussion about extending the [csv] interface to
provide data conversions to different types. If such a use case is to be
supported, what would be the best approach to integrate a library like
[convert]? Doing all required conversions manually would probably mean a
b
16 matches
Mail list logo
