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:
> >
> > Converter<F,T> createConverterPath(Class<F> fromType, Class<T> 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.
> >
>
> The problem is that this stuff becomes pretty fast very complex.
> Therefore, a strategy could be to handle this in separate layers.
>
> - There would be a core layer providing basic converters from type A to
> B. AIUI, this is what [convert] currently has.
> - Then there is a layer of handling more complex conversions, e.g. the
> transitive stuff and maybe also conversions with collections and arrays
> involved. I guess, to implement this layer, you will need a registry and
> some more meta data about the converters available.
> - Another layer would be an integration layer into custom applications.
> Here different patterns could be provided for triggering conversions
> with more or less magic.
>
> Oliver
>
> >
> > On Thu, Aug 15, 2013 at 9:24 AM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> >> On Thu, Aug 15, 2013 at 9:09 AM, James Carman <
> ja...@carmanconsulting.com>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 conversions.
> >>>
> >>
> >> Yes, and be careful of the shortest path too:
> >>
> >> I can have:
> >>
> >> String -> Long
> >> String -> Date
> >> Date -> Long
> >>
> >> So when I ask for String -> Long, I do not want String -> Date -> Long!
> >>
> >> I have something like this at work I use for for (complex) objects.
> >>
> >> The other aspect is caching, let's say I have a Customer and I want to
> >> convert it to XML and JSON, I want to cache the results of the
> conversion
> >> and invalidate that cache if I change the customer. Is that out of
> scope? I
> >> would be some kind of project object that holds on to a Customer, a JSON
> >> string, and an XML document (both bytes and String).
> >>
> >> Gary
> >>
> >>
> >>>
> >>>
> >>> On Thu, Aug 15, 2013 at 8:00 AM, Gary Gregory <garydgreg...@gmail.com>
> >>> wrote:
> >>>> Should the framework try to convert transitively?
> >>>>
> >>>> Gary
> >>>>
> >>>> On Aug 15, 2013, at 6:56, James Carman <ja...@carmanconsulting.com>
> >>> wrote:
> >>>>
> >>>>> I personally think we're over-thinking this thing. Keep it simple,
> >>> folks:
> >>>>>
> >>>>> public interface Converter<F,T>
> >>>>> {
> >>>>> 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
> >>>>> <joerg.schai...@scalaris.com> wrote:
> >>>>>> 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 of a static
> import
> >>>>>>> and a very concise syntax like:
> >>>>>>>
> >>>>>>> Integer columnInt = to(Integer.class, record.getValue(1));
> >>>>>>>
> >>>>>>>
> >>>>>>> That being said, [convert] could offer several patterns to perform
> >>> type
> >>>>>>> conversion, and the use of proxies could be one of them.
> >>>>>>
> >>>>>> I never had a look at [convert], but this proposed syntax reminds me
> >>>>>> strongly to an own little framework, where I have following methods
> in
> >>> an
> >>>>>> interface to convert strings into arbitrary objects:
> >>>>>>
> >>>>>> ================= %< ==============
> >>>>>> <T> T get(Class<T> type, String key);
> >>>>>> <T> T get(ValueConverter<T> converter, String key);
> >>>>>> ================= %< ==============
> >>>>>>
> >>>>>> The value c
