[
Lists Home |
Date Index |
Thread Index
]
- To: Bill de hÓra <bill.dehora@propylon.com>,"Elliotte Harold" <elharo@metalab.unc.edu>
- Subject: RE: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")
- From: "Dare Obasanjo" <dareo@microsoft.com>
- Date: Thu, 17 Feb 2005 13:21:03 -0800
- Cc: "XML Developers List" <xml-dev@lists.xml.org>
- Thread-index: AcUVLZfF/BYcB6EsRJ6UCyntLujhTQACJMkw
- Thread-topic: [xml-dev] What should TrAX look like? (Was: Re: [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")
> -----Original Message-----
> From: Bill de hÓra [mailto:bill.dehora@propylon.com]
> Sent: Thursday, February 17, 2005 12:14 PM
> To: Elliotte Harold
> Cc: 'XML Developers List'
> Subject: Re: [xml-dev] What should TrAX look like? (Was: Re:
> [xml-dev] Article on JAXP 1.3 "Fast and Easy XML Processing")
>
>
> I thought I had already indicated:
>
> - that a heavily overloaded method indicates a missing
> abstraction [1]
>
> - that Source is not ideal, but a better basis for
> evolution than a class with a heavily overloaded method.
I find it interesting you claim this when in other responses to this thread Elliote has basically been discussing porting the .NET model to Java (streaming abstraction = XmlReader, tree model abstraction = IXPathNavigable). A model where I can implement an API that accepts an interface yet still have to mess around with casting indicates that there is a missing abstraction (i.e Source). On the other hand it seems you have confused the existence of multiple abstractions to deal with multiple use cases (streaming vs. in-memory XML, text output vs. xml output) as some sort of flaw in the .NET design.
--
PITHY WORDS OF WISDOM
No matter how long or how hard you shop for an item, after you've bought it, it will be on sale somewhere cheaper.
This posting is provided "AS IS" with no warranties, and confers no rights.
|