You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Simon Bretin <si...@anyware-tech.com> on 2003/11/04 09:28:05 UTC
CharacterDataImpl Hierarchy
Hello Xerces developpers,
I have been working with Xerces for quite some times now but just as a
simple user. I'm currently working on a project where I try to reduce
to the bare minimum the size of java applications, by doing some
bytecode optimization.
Within this work I found a little problem with the class
org.apache.xerces.dom.CharacterDataImpl. This class extends ChildNode
but does not implement CharacterData which would seem like the correct
thing to do. Since this is an abstract class, the class extending
CharacterDataImpl (which is abstract) will also implement CharacterData,
thus making the hierarchy somewhat correct.
I was wondering if there was a true reason behind this miss, or if my
understanding of the hierarchy of this class was incorrect ?
Thanks,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: CharacterDataImpl Hierarchy
Posted by Simon Bretin <si...@anyware-tech.com>.
I agree with you on those points. But you cannot say that his is pure OO
conception if one class implements methos from a child class's interface ...
I understand all what you guys said, and my problem is that I saw my
optimization problems thinking of pure OO conception ... I have to
re-think it in more practical way !
Simon
Joseph Kesselman wrote:
>
>
>
>
>>ProcessingInstructionImpl inheriting from CharacterDataImpl pulls in some
>>methods that belong to CharacterData which aren't relevant to its
>>behaviour.
>>
>>
>
>True, but since they aren't exposeed via the ProcessingInstruction
>interface, nobody outside the DOM implementation itself should be able to
>tell the difference.
>
>Remember, there is no guarantee that the DOM node types are each
>implemented by a unique class... or that they don't implement other non-DOM
>interfaces as well. As an application programmer, you can't reliably use
>instanceOf or reflection to identify the node's type; you have to ask it
>for its type value.
>
>Xalan, for example, includes a DOM proxy where all node types are
>implemented by a single class. That means a large number of the object's
>methods are invalid for any given node... but nobody should be calling them
>in those cases, so nobody should care. If you operate it via the DOM APIs,
>everything works.
>
>______________________________________
>Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
>"The world changed profoundly and unpredictably the day Tim Berners Lee
>got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: CharacterDataImpl Hierarchy
Posted by Joseph Kesselman <ke...@us.ibm.com>.
>ProcessingInstructionImpl inheriting from CharacterDataImpl pulls in some
>methods that belong to CharacterData which aren't relevant to its
>behaviour.
True, but since they aren't exposeed via the ProcessingInstruction
interface, nobody outside the DOM implementation itself should be able to
tell the difference.
Remember, there is no guarantee that the DOM node types are each
implemented by a unique class... or that they don't implement other non-DOM
interfaces as well. As an application programmer, you can't reliably use
instanceOf or reflection to identify the node's type; you have to ask it
for its type value.
Xalan, for example, includes a DOM proxy where all node types are
implemented by a single class. That means a large number of the object's
methods are invalid for any given node... but nobody should be calling them
in those cases, so nobody should care. If you operate it via the DOM APIs,
everything works.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: CharacterDataImpl Hierarchy
Posted by Michael Glavassevich <mr...@apache.org>.
Hi Arnaud,
I don't think it violates OO concepts either. What I meant was that
ProcessingInstructionImpl inheriting from CharacterDataImpl pulls in some
methods that belong to CharacterData which aren't relevant to its
behaviour.
On Tue, 4 Nov 2003, Arnaud Le Hors wrote:
> Unless I missed something I don't think it violates any OO concepts. But
> that's how things ended up being after the complete rearrangement of the
> code I made to optimize memory usage. I would agree that the name is
> misleading but I was hoping the comment I wrote and Michael quoted would
> make things clear.
> I think we could safely rename it if we feel compelled to.
> --
> Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
---------------------------
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: CharacterDataImpl Hierarchy
Posted by Arnaud Le Hors <le...@us.ibm.com>.
Unless I missed something I don't think it violates any OO concepts. But
that's how things ended up being after the complete rearrangement of the
code I made to optimize memory usage. I would agree that the name is
misleading but I was hoping the comment I wrote and Michael quoted would
make things clear.
I think we could safely rename it if we feel compelled to.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
Simon Bretin wrote:
> Allright, I understand this is definitly a misleading name and/or an OO
> conception problem ....
>
> Thanks for the clarification.
>
> Simon
>
> Joseph Kesselman wrote:
>
>>
>>
>>
>>
>>> Perhaps this isn't the cleanest way of doing this from an OO point of
>>>
>>
>> view, but it gets the job done.
>>
>> The real glitch here is that CharacterDataImpl's name is misleading; it
>> should probably have been called something like NodeCarryingTextImpl. If
>> you want to blame someone for that, it's probably my fault.
>>
>> But CharacterDataImpl is strictly an implementation detail; nobody but a
>> Xerces implementer should ever have to be particularly aware of it. So
>> this
>> should, at worst, be a minor documentation nuisance.
>>
>> Theoretically, we could rename it and nobody's code ought to break... but
>> I'd want to poll the user community before we considered that; some folks
>> have done weird things with internal classes in the past, and we'd
>> need to
>> balance the impact on them vs. long-term code clarity.
>>
>> ______________________________________
>> Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
>> "The world changed profoundly and unpredictably the day Tim Berners Lee
>> got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
>> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>>
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: CharacterDataImpl Hierarchy
Posted by Simon Bretin <si...@anyware-tech.com>.
Allright, I understand this is definitly a misleading name and/or an OO
conception problem ....
Thanks for the clarification.
Simon
Joseph Kesselman wrote:
>
>
>
>
>>Perhaps this isn't the cleanest way of doing this from an OO point of
>>
>>
>view, but it gets the job done.
>
>The real glitch here is that CharacterDataImpl's name is misleading; it
>should probably have been called something like NodeCarryingTextImpl. If
>you want to blame someone for that, it's probably my fault.
>
>But CharacterDataImpl is strictly an implementation detail; nobody but a
>Xerces implementer should ever have to be particularly aware of it. So this
>should, at worst, be a minor documentation nuisance.
>
>Theoretically, we could rename it and nobody's code ought to break... but
>I'd want to poll the user community before we considered that; some folks
>have done weird things with internal classes in the past, and we'd need to
>balance the impact on them vs. long-term code clarity.
>
>______________________________________
>Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
>"The world changed profoundly and unpredictably the day Tim Berners Lee
>got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: CharacterDataImpl Hierarchy
Posted by Joseph Kesselman <ke...@us.ibm.com>.
> Perhaps this isn't the cleanest way of doing this from an OO point of
view, but it gets the job done.
The real glitch here is that CharacterDataImpl's name is misleading; it
should probably have been called something like NodeCarryingTextImpl. If
you want to blame someone for that, it's probably my fault.
But CharacterDataImpl is strictly an implementation detail; nobody but a
Xerces implementer should ever have to be particularly aware of it. So this
should, at worst, be a minor documentation nuisance.
Theoretically, we could rename it and nobody's code ought to break... but
I'd want to poll the user community before we considered that; some folks
have done weird things with internal classes in the past, and we'd need to
balance the impact on them vs. long-term code clarity.
______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: CharacterDataImpl Hierarchy
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Simon,
If you have a look at the Javadoc for CharacterDataImpl it says: "Since
ProcessingInstructionImpl inherits from this class to reuse the
setNodeValue method, this class isn't declared as implementing the
interface CharacterData. This is done by relevant subclasses (TexImpl,
CommentImpl)." This was an implementation decision to reuse code in
exchange for pushing down interface inheritence to subclasses. Since a
ProcessingInstruction is not also CharacterData it shouldn't be accessible
through this type. Also, keep in mind that both Text and Comment are
subinterfaces of CharacterData, so explicitly specifying that their
implmentors also implment CharacterData is just added sugar. Perhaps this
isn't the cleanest way of doing this from an OO point of view, but it gets
the job done.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
Simon Bretin <si...@anyware-tech.com>
11/04/2003 09:19 AM
Please respond to
xerces-j-dev
To
xerces-j-dev@xml.apache.org
cc
Subject
Re: CharacterDataImpl Hierarchy
Hi Michael,
First thanks for the answer !
However I don't really get your point. If I'm not mistaken, all the
methods of CharacterData are already implemented by CharacterDataImpl
.... So the fact that ProcessingInstructionImpl doesn't implement
CharacterData does not seem relevant to me ...
What bugs me is that CommentImpl implements CharacterData but the
methods actually implementing this interface are coming from the
CharacterDataImpl which from a Hierarchy point of view has nothing to do
with the CharacterData interface ... The naming of the two classes,
whiwh must have been chosen appropriatly, adds even more to this point
because usually ClassImpl implements the Interface Class.
Do you see my point ?
Simon
Re: CharacterDataImpl Hierarchy
Posted by Simon Bretin <si...@anyware-tech.com>.
Hi Michael,
First thanks for the answer !
However I don't really get your point. If I'm not mistaken, all the
methods of CharacterData are already implemented by CharacterDataImpl
.... So the fact that ProcessingInstructionImpl doesn't implement
CharacterData does not seem relevant to me ...
What bugs me is that CommentImpl implements CharacterData but the
methods actually implementing this interface are coming from the
CharacterDataImpl which from a Hierarchy point of view has nothing to do
with the CharacterData interface ... The naming of the two classes,
whiwh must have been chosen appropriatly, adds even more to this point
because usually ClassImpl implements the Interface Class.
Do you see my point ?
Simon
Michael Glavassevich wrote:
>Hi Simon,
>
>The reason org.apache.xerces.dom.CharacterDataImpl doesn't implement
>CharacterData is because one of its derived classes,
>org.apache.xerces.dom.ProcessingInstructionImpl, doesn't implement this
>interface. The ProcessingInstruction interface only extends Node.
>
>
>The other two subclasses for comment nodes and text nodes implement
>CharacterData as they should.
>
>On Tue, 4 Nov 2003, Simon Bretin wrote:
>
>
>
>>Hello Xerces developpers,
>>
>>I have been working with Xerces for quite some times now but just as a
>>simple user. I'm currently working on a project where I try to reduce
>>to the bare minimum the size of java applications, by doing some
>>bytecode optimization.
>>Within this work I found a little problem with the class
>>org.apache.xerces.dom.CharacterDataImpl. This class extends ChildNode
>>but does not implement CharacterData which would seem like the correct
>>thing to do. Since this is an abstract class, the class extending
>>CharacterDataImpl (which is abstract) will also implement CharacterData,
>>thus making the hierarchy somewhat correct.
>>I was wondering if there was a true reason behind this miss, or if my
>>understanding of the hierarchy of this class was incorrect ?
>>
>>Thanks,
>>
>>Simon
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
>>For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>>
>>
>
>---------------------------
>Michael Glavassevich
>XML Parser Development
>IBM Toronto Lab
>E-mail: mrglavas@ca.ibm.com
>E-mail: mrglavas@apache.org
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Re: CharacterDataImpl Hierarchy
Posted by Michael Glavassevich <mr...@apache.org>.
Hi Simon,
The reason org.apache.xerces.dom.CharacterDataImpl doesn't implement
CharacterData is because one of its derived classes,
org.apache.xerces.dom.ProcessingInstructionImpl, doesn't implement this
interface. The ProcessingInstruction interface only extends Node.
The other two subclasses for comment nodes and text nodes implement
CharacterData as they should.
On Tue, 4 Nov 2003, Simon Bretin wrote:
> Hello Xerces developpers,
>
> I have been working with Xerces for quite some times now but just as a
> simple user. I'm currently working on a project where I try to reduce
> to the bare minimum the size of java applications, by doing some
> bytecode optimization.
> Within this work I found a little problem with the class
> org.apache.xerces.dom.CharacterDataImpl. This class extends ChildNode
> but does not implement CharacterData which would seem like the correct
> thing to do. Since this is an abstract class, the class extending
> CharacterDataImpl (which is abstract) will also implement CharacterData,
> thus making the hierarchy somewhat correct.
> I was wondering if there was a true reason behind this miss, or if my
> understanding of the hierarchy of this class was incorrect ?
>
> Thanks,
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
---------------------------
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org