From Arved_37@chebucto.ns.ca Wed Jul 12 00:34:03 2000 Return-Path: Mailing-List: contact general-help@xml.apache.org; run by ezmlm Delivered-To: mailing list general@xml.apache.org Received: (qmail 15445 invoked from network); 12 Jul 2000 00:34:03 -0000 Received: from chebucto.ns.ca (HELO halifax.chebucto.ns.ca) (192.75.95.75) by locus.apache.org with SMTP; 12 Jul 2000 00:34:03 -0000 Received: from Dyip-53.chebucto.ns.Ca ([192.75.95.53]:1027 "HELO localhost.localdomain") by halifax.chebucto.ns.ca with SMTP id ; Tue, 11 Jul 2000 21:33:45 -0300 From: Arved Sandstrom Reply-To: Arved_37@chebucto.ns.ca To: general@xml.apache.org Subject: Re: [spinnaker] Announce Date: Tue, 11 Jul 2000 21:22:53 -0300 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain; charset=US-ASCII References: <004901bfeb59$5e91e6a0$de170609@cupertino.ibm.com> <01b601bfeb8f$2708c4c0$a056b8d1@swbell.net> In-Reply-To: <01b601bfeb8f$2708c4c0$a056b8d1@swbell.net> MIME-Version: 1.0 Message-Id: <00071121305000.00952@localhost.localdomain> Content-Transfer-Encoding: 7BIT I don't buy that argument. I can think of a number of situations where we have to take implementation into account at high-level design time; I don't think this is one of them. It would be a mistake to accord Java some paramount status here. Not everyone (myself included) is enthralled with it. Let's push for high-level designs that can accommodate any OO language; if the first implementation happens to be Java so be it. Arved Sandstrom On Tue, 11 Jul 2000, Eric Hodges wrote: > C++ and Java are fundamentally different languages. Java uses some of C++'s > syntax, but that's it. I vote that a Java version be developed, and any > good strategies that show up AND work well in C++ be appropriated when the > C++ version is developed. But trying to find one design that fits both > languages well will produce one design that doesn't quite fit either > language. > > > ----- Original Message ----- > From: "Andy Heninger" > To: > Sent: Tuesday, July 11, 2000 11:59 AM > Subject: Re: [spinnaker] Announce > > > > The C++ and Java code for a parser will clearly not be identical - they > > are different languages - but there's much to be gained by keeping the > > overall architecture and design the same between the two versions. > > > > The existing xerces-C scanner is a fundamentally different code base from > > xerces-j, at least in part because some of those tweaky Java optimizations > > seemed to dominate the design of xerces-j. > > > > At some point XML schema will need to be done for C++, and I certainly > > hope that we [whoever actually ends up doing the work] will be able to use > > the design for schema support from xerces-J pretty much intact. > > > > Knowing that there will be both a Java and a C++ implementation of a given > > design does impose some constraints, but they're not too bad - a little > > extra thought on how memory management will work, don't rely too heavily > > on introspection and the like. And it doesn't mean that the C++ code > > needs to come out looking like the Xerces C++ DOM, which was set up as a > > minimum effort port from Java. > > > > But if we don't think about the issues up front, when doing the initial > > architecture, we run the risk of having to do a complete redesign for C++, > > which would be a big waste of time and effort. > > > > Andy Heninger > > IBM XML Technology Group, Cupertino, CA > > heninger@us.ibm.com > > > > > > > > From: "James Duncan Davidson" > > > > > > > on 7/10/00 2:05 PM, Joe Polastre at polastre@jtcsv.com wrote: > > > > > > > I'd also like to see this be coordinated with the xerces-c developers > > since > > > > the source base for xerces-c is based on the original xerces-j. it > > would be > > > > nice to keep the two parsers in sync so that changes to one parser and > > > > relatively easy to implement in the other. plus, i haven't seen > > anyone > > > > comment on the implications towards the c++ parser by starting a new > > branch > > > > that could possibly become the new xerces-j. [us C++ developers are > > real > > > > people too!] > > > > > > I disagree. I don't think that keeping sync across C++ and Java is > > > reasonable given that two very different coding strategies really should > > be > > > used to make each appropriate for it's environment. > > > > > > I think that the feature sets and goals should be similar -- SAX, DOM... > > But > > > the implementation should be different. > > > > > > > > > > > --------------------------------------------------------------------- > > In case of troubles, e-mail: webmaster@xml.apache.org > > To unsubscribe, e-mail: general-unsubscribe@xml.apache.org > > For additional commands, e-mail: general-help@xml.apache.org > > > > > --------------------------------------------------------------------- > In case of troubles, e-mail: webmaster@xml.apache.org > To unsubscribe, e-mail: general-unsubscribe@xml.apache.org > For additional commands, e-mail: general-help@xml.apache.org -- Senior Developer e-plicity.com (www.e-plicity.com) Halifax, Nova Scotia "B2B Wireless in Canada's Ocean Playground"