[
Lists Home |
Date Index |
Thread Index
]
Dare Obasanjo wrote:
>>-----Original Message-----
>>From: Paul R Brown [mailto:prb@fivesight.com]
>>Sent: Thursday, February 17, 2005 11:14 AM
>>To: 'XML Developers List'
>>Cc: 'Elliotte Harold'; Michael Kay
>>Subject: Re: [xml-dev] What should TrAX look like? (Was: Re:
>>[xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")
>>
>>
>>I also go so far as to say that the discussion is a bit misdirected:
>>the apparently poor encapsulation of Source is more of a
>>symptom of the fact that TrAX transformers (e.g., XSLT
>>processors but potentially STX or XQuery or...?) need to be
>>able to implement their underlying model however they so
>>choose. Source is little more than a marker interface, and
>>the thing that makes sense (at least to me) is to have
>>off-the-beaten-path Source implementations (e.g., for a pull
>>parser) exhibit enough polymorphism (implement SAXSource,
>>DOMSource, etc.) to make them useful and reasonably portable
>>for consumption by different Transformer implementations.
>
>
> Marker interface is a synonym for design flaw.
A marker interface is just that - a marker. The design flaw happens when
you leave it there and don't fill it out.
Casting is a way to get answers on-demand, parametric polymorphism is
way to supply answers for the questions you knew about upfront. I still
think there's a need here for an object that can answer questions about
what's being transformed. The exception to that is if you know that
there are precious few questions - then polymorphism works a treat - I
don't get that sense in this case.
cheers
Bill
|
