xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Hodges <harmo...@swbell.net>
Subject Re: [spinnaker] Announce
Date Wed, 12 Jul 2000 01:03:32 GMT
Will the high level design make use of multiple inheritance?  If so, the
Java code will be ugly.  If not, we're removing a useful feature of C++.
That's the sort of problem I'm worried about.  Perhaps you are thinking of a
higher level design, perhaps just components and packages without any class
design?

I'm not enthralled with Java, either.  I just thought the first product
would be in Java.

----- Original Message -----
From: "Arved Sandstrom" <Arved_37@chebucto.ns.ca>
To: <general@xml.apache.org>
Sent: Tuesday, July 11, 2000 7:22 PM
Subject: Re: [spinnaker] Announce


> 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" <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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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"
>
> ---------------------------------------------------------------------
> 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
>


Mime
View raw message