Mailing-List: contact general-help@xml.apache.org; run by ezmlm
Date: Tue, 11 Jul 2000 18:23:23 -0500
From: Eric Hodges <harmony2@swbell.net>
Subject: Re: [spinnaker] Announce
To: general@xml.apache.org
Message-id: <01b601bfeb8f$2708c4c0$a056b8d1@swbell.net>
Organization: Mongoose Technology Inc.
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
References: <B58F8F8B.743C%james.davidson@eng.sun.com>
 <004901bfeb59$5e91e6a0$de170609@cupertino.ibm.com>

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" <andyh@jtcsv.com>
To: <general@xml.apache.org>
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" <james.davidson@eng.sun.com>
>
>
> > 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
>