[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schema equivClass.

• From: Stefan Haustein <haustein@k...>
• To: Steve Harris <sharris@p...>
• Date: Fri, 04 Feb 2000 10:23:13 +0100

> > BTW, a similar problem exists in C++:
> >
> > consider class A, class B extends A
> >
> > you cannot assign an instance of B to an A variable because it may
> > consume more memory and thus not fit...
> 
> If B extends A, then A was probably not designed to accept assignment
> from the then-unknown type B. You can slice B to cram it into A, but
> of course you shouldn't. I'm not sure of any scenario where you would
> want to assign a concrete B to a concrete A.

Can you please explain me then why Michael Anderson expected 
exactly this behaviour in XML Schema? If OOP is watered for 
efficency or legacy reasons in C++, that's OK to me. But when
creationg something new like XML Schema, it's probably a good 
chance to do it a bit more elegant. 

> We use the Standard C++ containers with pointers all the time. You can
> take a container of A*'s, put your A*'s and B*'s (and any other types
> derived from A) into it, and call polymorphic methods on the elements
> using the std::mem_fun* functors.

Ah, that sounds very elegant. Did you ever tell that a Smalltalk
programmer? He'll probably switch to C++ immediately <g>

Best regards

Stefan

• Follow-Ups:
  • Re: XML Schema equivClass.
    • From: Steve Harris <sharris@p...>

• References:
  • Re: XML Schema equivClass.
    • From: Steve Harris <sharris@p...>

• Prev by Date: Re: XML Mentioned in Mainstream Commercial
• Next by Date: Re: Namespace prefix question
• Previous by thread: Re: XML Schema equivClass.
• Next by thread: Re: XML Schema equivClass.
• Index(es):
  • Date
  • Thread