Inherited method doesn't as expected

Hi,
I have a situation like this:
public class Parent {
     private String a = "a";
     public void go() { System.out.println(a); }
public static void main(String args[]) {
          Child child = new Child();
          child.go();
class Child extends Parent {
     public String a = "b";
I expect this to print "b", but it prints "a".
Can anyone explain this, please?
Tnx

Thanks for your response, but ... sorry ... I still
don't understand it exactly.
There is one object, but since the variable a is
declared private in Parent, I don't expect that
variable to be present in the object since the object
is instanciated with new Child().Of course it's present in the object. The object has everything that is in the parent, grandparent, child, etc.--everything from every class up the tree. Not everything is accessible from everywhere, however. Code in the child class can't access private members of the parent class, for instance. But in this case, since the method we're executing is defined in the parent, that method can access the parent's private members.

Similar Messages

  • BUG? @Transactional doesn't work on inherited methods

    Hi all,
    I have to state an odd behaviour:
    I have a DAO interface :
    public interface UserDAO
    ..public User save(User user);
    In my application I have to use this UserDAO interface to rebuild the DAO layer with a Toplink database access. The new UserDAO implementation is injected into the original ServiceLayer. The according UserService looks like :
    public interface UserService
    ..public User save(User user);
    And the implementation :
    public class UserServiceImpl
    ..protected UserDAO userDAO;
    ..public User save(User user)
    ....userDAO.save(user);
    ..public setUserDAO(UserDAO userDAO)
    ....this.userDAO = userDAO;
    However, until I can save my user objects with Toplink I have to annotade the UserService as transactional. Therefore I would write a new UserService class, exending from the original one, like this :
    import org.springframework.transaction.annotation.Transactional;
    @Transactional
    public class TransactionalUserService extends UserServiceImpl
    And thats all, since I can inject my JPA UserDAO into this TransactionalUserService and everything will work right.
    --> BUT NO ! In this case nothing happens transactional. It only works, when I rewrite the UserService. Then I have :
    @Transactional
    public class TransactionalUserService implements UserService
    ..private UserDAO userDAO;
    ..public User save(User user)
    ....userDAO.save(user);
    ..public setUserDAO(UserDAO userDAO)
    ....this.userDAO = userDAO;
    Now my user objects are stored into the database. But why only in this case and not with inherited methods ?

    Spring is the one managing your transactions and @Transactional is a Spring annotation so you might get a quick answer to your question on the Spring Data Access Forum.
    That being said, instead of subclassing UserServiceImpl just to add @Transactional you could instead use <tx:advice> in your Spring XML configuration to make UserServiceImpl transactional.
    --Shaun                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • LVOOP "call parent method" doesn't work when used in sibling VI

    It seems to me that the "call parent method" doesn't work properly according to the description given in the LabVIEW help.
    I have two basic OOP functions I am doing examples for. I can get one to work easily and the other one is impossible.
    Background
    There are 3 basic situations in which you could use the "call parent method"
    You are calling the parent VI (or method) of a child VI from within the child VI
    You are calling the parent VI (or method) of a child VI from within a sibling VI
    You are calling the parent VI (or method) of a child VI from a different class/object.
    From the LabVIEW help system for "call parent method":
    Calls the nearest ancestor implementation of a class method. You can use the Call Parent Method node only on the block diagram of a member VI that belongs to a class that inherits member VIs from an ancestor class. The child member VI must be a dynamic dispatching member VI and have the same name as the ancestor member VI
    From my reading of that it means situation 3 is not supported but 1 & 2 should be.
    Unfortunately only Situation 1 works in LabVIEW 2012.
    Here is what I want
    And this is what I actually get
    What this means is that I can perform a classic "Extend Method" where a child VI will use the parent's implementation to augment it's functions BUT I cannot perform a "Revert Method" where I call the parent method's implementation rather than the one that belongs to the object.
    If you want a picture
    Any time I try and make operation2 the VI with the "call parent method" it shows up for about 1/2 sec and then turns into operation.
    So there are only 3 possibilities I can see
    Bug
    Neither situation 2 or 3 are intended to work (see above) and the help is misleading
    I just don't know what I am doing (and I am willing to accept this if someone can explain it to me)
    The downside is that if situation 2 above doesn't work it does make the "call parent node" much less usefull AND it's usage/application just doesn't make sense. You cannot just drop the "call parent node" on a diagram, it only works if you have an existing VI and you perform a replace. If you can only perform situation 1 (see above) then you should just drop the "call parent node" and it picks up the correct VI as there is only 1 option. Basically if situation 2 is not intended to work then the way you apply "call parent method" doesn't make sense.
    Attachements:
    For the really keen I have included 2 zip files
    One is the "Revert Method labVIEW project" which is of course not working properly because it wants to "call parent method" on operation not operation2
    The other zip file is all pictures with a PIN for both "Revert Method" and "Extend Method" so you can see the subtle but important differences and pictrures of the relavant block diagrams including what NI suggested to me as the original fix for this problem but wasn't (they were suggesting I implement Extend Method).
     If you are wondering where I got the names, concepts and PIN diagrams from see:
    Elemental Design Patterns
    By: Jason McColm Smith
    Publisher: Addison-Wesley Professional
    Pub. Date: March 28, 2012
    Print ISBN-10: 0-321-71192-0
    Print ISBN-13: 978-0-321-71192-2
    Web ISBN-10: 0-321-71255-2
    Web ISBN-13: 978-0-321-71255-4
     All the best
    David
    Attachments:
    Call parent node fault.zip ‏356 KB
    Call parent node fault.zip ‏356 KB

    Hi tst,
    Thankyou for your reply. Can you have a look at my comments below on the points you make.
    1) Have to disagree on that one. The help is unfortunately not clear. The part you quote in your reply only indicates that the VI you are applying "Call Parent Node" to must be dynamic dispatch. There is nowhere in the help it actually states that the call parent node applies to the VI of the block diagram it is placed into. Basically case 2 in my example fulfills all that the help file requires of it. The dynamic dispatch VI's operation are part of a class that inherits from a given ancestor. Operation 2 for Reverted behaviour is a child VI that is dynamic dispatch and has the same name as the ancestor VI (operation2). The help is missing one important piece of information and should be corrected.
    2) True it does work this way. I was trying to build case 2 and had not yet built my ancestor DD for operation so the function dropped but wasn't associated with any VI. I was able to do this via a replace (obviously once the ancestor Vi was built) so this one is just bad operator
    3) Keep in mind this is an example not my end goal. I have a child implementation because this is a case where I am trying to do a "reverse override" if you like.
    3a) The point of the example is to override an objects method (operation2) with it's parent's method NOT it's own. The reason there is a child implementation with specific code is to prove that the parent method is called not the one that relates to the object (child's VI). If I start having to put case structures into the child VI I make the child VI have to determine which code to execute. The point of Revert method is to take this function out of the method that is doing the work. (Single Use Principal and encapsulation)
    3b) The VI I am calling is a Dynamic Dispatch VI. That means if I drop the superclass's VI onto the child's block diagram it will become the child's implementation. Basically I can't use Dynamic Dispatch in this case at all. It would have to be static. That then means I have to put in additional logic unless there is some way to force a VI to use a particular version of a DD VI (which I can't seem to find).
    Additional Background
    One of the uses for "Revert Method" is in versioning.
    I have a parent Version1 implementation of something and a child Version2. The child uses Version2 BUT if it fails the error trapping performs a call to Version1.
    LabVIEW has the possibility of handling the scenario but only if both Case 1 and Case 2 work. It would actually be more useful if all 3 cases worked.
    The advantage of the call parent method moving one up the tree means I don't have the track what my current object is and choose from a possible list, if, for example the hierarchy is maybe 5 levels deep. (so V4 calls V3 with a simple application of "call parent method" rather than doing additional plumbing with case structures that require care and feeding). Basically the sort of thing OOP is meant to help reduce. Anything that doesn't allow case 2 or 3 means you have to work around the limitation from a software design perspective.
    If at the end of the day Case 2 and case 3 don't and won't ever work then the help file entry needs to be fixed.
    All the best
    David

  • Overriding Inherited methods

    why cant we override the inherited methods with more secure access modifier (private)..... while if we do the apposite ie override with more non secure access modifiers , java is able to distinguish them and call the appropriate method or pop up the syntax error.. i am not able to understand the concept ... if any one could give a practical example it would helpful to me to understand...

    rajeshrocks25 wrote:
    Hey, correct me i am wrong.
    When we inherit Java loads all the members of the super class and we override or hide them then it simply ignores the superclass members ri8???
    thats what happening in the above code?I strongly suggest rereading the tutorial for Polymorphism or searching Google for alternative explanations for "Java Polymorphism", it doesn't sound like the concept has fully sunk in yet. As for a direct answer, at the bottom of the polymorphism tutorial I linked earlier they mention:
    The Java virtual machine (JVM) calls the appropriate method for the object that is referred to in each variable. It does not call the method that is defined by the variable's type. This behavior is referred to as virtual method invocation and demonstrates an aspect of the important polymorphism features in the Java language.To add, if the object being referred to does not contain the appropriate method, then the JVM will look for an appropriate method in the superclass, and the superclass of the superclass until the appropriate method is found.
    Also to clarify your confusion earlier, if a subclass A extends a class B, then A is considered a B so there is no use in casting A to B. In a more practical sense, imagine a [Boy] extending a [Man]. The [Boy] is of course a [Boy] because that is what we have defined him as. But the [Boy] is also a [Man] because he extends the [Man]. Therefore casting a [Boy] into a [Man] is pointless, because he already is indeed a [Man], just a subclass in the form of a [Boy].
    Furthermore if we declare a [Man] and instantiate him with a [Boy] then invoking a method talk(), [Boy] is inspected for the appropriate method talk(), if it has not been overridden then the JVM will look in [Man] and calls the appropriate method. Alternatively if we declare a [Man] and instantiate him as a [Man] then invoking the method talk(), [Man] is inspected for the appropriate method. It might also be of worth to note the instantiated [Man] cannot be cast into a [Boy], because a [Boy] is a subclass of [Man] and may contain properties or methods undefined by [Man].
    Mel

  • I cannot figure out how to make the text larger on an incoming email.  The finger method doesn't work and I cannot find any toolbar with which to do it.  I could find nothing in settings also.  Plese help and thank you.

    I cannot figure out how to make the text larger in a received email.  The finger method doesn't work and I can find no tool bar as I can for composing emails.  I can find nothing in settings.  Please help and thank you in advance.

    Hi there,
    Download a piece of software called TinkerTool - that might just solve your problem. I have used it myself to change the system fonts on my iMac. It is software and not an app.
    Good wishes,
    John.

  • Central Autoreaction Method doesn't work for NW 7.10 in SolMan 7.01

    Hello!
    The central autoreaction method doesn't work for the satellite system
    NW 7.10. For systems with kernel releases 4.6D, 640, 700 this method
    works fine and e-mail alerts are coming.
    The configuration steps I've checked:
    1. Configured SCOT. The mail_send job executes every 5 minutes.
    2. Background dispatching job is released: SAP_CCMS_MONI_BATCH_DP (In
    central CEN/000/DDIC and satellite system SAT/000/DDIC)
    3. Central dispatching job is released: SAP_CCMS_CENSYS_DISPATCHER
    (Only in central system CEN/000/DDIC)
    4. The sapccm4x-agent registered as web service within CEN using
    Create Remote Monitoring for NW 7.10:
    Connection test to SAPCCM4X.<satellite_host>.00 was performed successfully
    5. Created a new autoreaction method by copying method
    CCMS_OnAlert_Email_V2 to the own Z_CCMS_Email_Alert_CEN:
    Function Module - SALO_EMAIL_IN_CASE_OF_ALERT_V2
    Execute Method on Any Server and Only in Central System, triggered by
    CCMS agents
    SENDER (EMAIL_USER) exists in CEN/000 , RECEPIENT - <distr list
    SAP_BASIS in CEN/000>, RECIPIENT-TYPEID - C
    6. Got MTE Classes from NW 7.10 satellite system and assigned this method
    Z_CCMS_Email_Alert_CEN to an MTE-class CCMS_ORAucPSAPSR3 for NW 7.10
    satellite system. The alert is red right now.
    7. The mail_send job doesn't send anything, in SCOT there are no
    sending orders.
    8. Autoreaction status on this alert in CEN in RZ20 - Sent to CEN.
    CEN_CHECKED.
    9. The alert status in RZ20 in CEN - ACTION_REQUIRED. If I execute it
    in manual the alert status changes to ACTIVE, but no email and no
    messages in sending orders in SCOT.
    Please help me to solve this issue.
    Thank you!

    Hi,
    Since you are using RECIPIENT-TYPEID =C i.e. General distribution list, pls ensure to have shared type of list created in SBWP.
    Also pls verify your SCOT configutaion , if apropriate address area i.e. *@abc.com
    Also one point to note that even if you trigger auto reaction method manually via RZ20 , pls check if alert is listed in SOST.
    if yes , that means there is problem in either SCOT configuration or distribution list.
    If alert is not appearing in SOST , that means you need to check auto reaction method parameters;
    Z_CCMS_OnAlert_Email_V2 , here check release section if Auto reaction execution method is checked.
    Regards,
    Rupali

  • How can I access the protected inherited method

    Hi guys:
    I know I can use getDeclaredMethod to get some methods,but my question how can I get a protected inherited method? for example
    class A{
    protected void test(){}
    class B extends A{
    public String getValue(){}
    class C{
    public static void main(Strin[] args){
    //at here I want to access "test" method by reflection,but I dont know how?
    thanks advance!

    Indeed it does. If you want to find the declared methods of the superclass then you should be able to figure out how to do that: find the superclass, find its declared methods.

  • Parameters/exceptions of inherited methods or events cannot be changed

    Hi All, I want to add parameter in method BBP_MAP_AFTER_BAPI.
    but i got message "Parameters/exceptions of inherited methods or events cannot be changed".
    Could any one help me with this problem ?
    Thanks.
    Budituta

    You have to change method signatures at the highest superclass level. 
    I.e. if A is the superclass and B is the subclass of A, then if you want to change the signature of a method in B that is inherited from A, you have to change B.
    matt

  • "Blocking" inherited  methods

    I have a class, Inventory which I want to extend HashMap. However, I only want objects of certain types added to it, and in a certain way.
    To do this, I envisaged having public methods like :
    public Object put(MyType1 key, MyType2 value)...but then I want to prevent the use of the standard put method of the HashMap (ie. to "enforce" the above method). I attempted this by overriding it and declaring it private, but that isn't allowed by Java. Is there a way I can extend the class and not allow inherited methods to be used?
    I can see two (less than satisfactory) ways around this :
    1) Override the methods, but implement no functionality for general arguments. This has the drawback of not being picked up as an error if the method is used.
    2) Make the HashMap an instance variable. But that would involve a lot more rewriting of other code, and re-implementing methods I want to inherit.
    (There are a other methods I want to override, not just put, btw).

    2) Make the HashMap an instance variable. But that
    would involve a lot more rewriting of other code,
    and re-implementing methods I want to inherit.It shouldn't require much rewriting for existing client code as you could put helper methods into your new class. E.G.
    public int size()
      return myHashMap.size();
    }Theres only a few methods in HashMap so it wouldn't take too long to do. This also has the advantage that you are now able to have your own typesafe methods. E.G.
    public MyType2 put(MyType1 key, MyType2 value)
      return (MyType2)myHashMap.put(key, value);
    }Col

  • Inherited Method Conflict

    An inherited method which is not overridden should behave as if the class had that method itself, but I have found a polymorphism conflict where they act differently.
    Here is an example where a subclass provides a special method for the parent interface.
    public interface iOne { }
    public interface iTwo extends iOne { }
    public class Alpha
    {     public void a(iTwo i){;}     }
    public class Beta extends Alpha
    {     public void a(iOne i){;} }
    public class Delta implements iTwo { }
    public class Run
         public void run()
         { (new Beta()).a(new Delta()); }
    }Errors on compile.
    Run.java:9: reference to a is ambiguous, both method a(iTwo) in Alpha and method a(iOne) in Beta match
              b.a(d);
    but if the two methods are moved into the same class
    public class Alpha { }
    public class Beta extends Alpha
         public void a(iOne i){;}
         public void a(iTwo i){;}
    }It compiles and runs fine.
    Does anyone have any idea why this happens? I would prefer to keep the appropriate methods in the parent so they are re-useable.

    Let me see if I've got it by paraphrasing the section of the JLS that schapel pointed out:
    Let 'a' be a method name having 1 parameter 'i'
    - one declaration appears within a class Beta and the type of the parameter is iOne
    - the other declaration appears within a class Alpha and the type of the parameter is iTwo ...
    Then the method 'a' declared in Beta is more specific than the method declared in Alpha if and only if both of the following are true:
    1) Beta can be converted to Alpha by method invocation conversion. (personally I don't understand this line, how can you convert a class by 'method invocation conversion' ? shouldn't they have said 'convert..by casting'? If they essentially mean casting, then you can convert a Beta to an Alpha).
    2) 'i' (of type iOne) can be converted to iTwo by method invocation conversion. (you cannot convert an iOne to an iTwo).
    Note that if you reverse them and say:
    Then the method 'a' declared in Alpha is more specific than the method declared in Beta if and only if both of the following are true:
    1) Alpha can be converted to Beta by method invocation conversion. (an Alpha cannot be converted to a Beta)
    2) 'i' (of type iTwo) can be converted to iOne by method invocation conversion. (you can convert a iTwo to an iOne).
    Either way you look at it, both statements cannot be true, thus, there is no 'a' method that is more specific.

  • Redefinition / Overwriting of inherited method using class-builder

    Hi,
    I have a class which inherits some methods from it's baseclass. I want so overwrite ( re-define ) some of the methods from the baseclass using se80 / se24.
    How can this be done ?
    Best Regards,
    Frank

    Hi,
    <b>go se80</b> 1) enter the class name which u have inherited from the base class
    2) in the herarchy ...methods---->Inherited Methods
    3) right click on the method which u have to redifine.
    4) select redifine option.
    5) ur method will be placed under redifination list.
    6) go write the code
    note :- U cannot redifine final Method...Appropriate message will be shown
    save and activate.
    Mark Helpful answers
    Message was edited by: Manoj Gupta

  • Inherited class doesn't contain necessary methods

    Hi, all!
    Here's the problem (channeling Adrian Monk again): I've got a working agent-based model running as a Java app. Everything about the model works except that one of the GUI elements is only displaying 4 of the 6 necessary slider bars that tells the model how to initialize. That GUI element is built into the library that I'm using to construct this java app (RePast code library, you can see it at: http://repast.sourceforge.net/). The GUI class element is RangeWidget, which uses RangePropertyDescriptor to fill it up with the parameters for the slider bars. The RangeWidget in my GUI has space for only 4 of the sliders bars; I've never had to modify a class from its default values. I need some advice. Do I (a) build a personalized RangeWidget class and call it as one of the subservient classes in my main Model.java; (b) import RangeWidget into my main Model.java and explicitly change the values in a separate method next to the RangePropertyDescriptor method; or (c) do something I'm not yet aware of?

    Here--I THINK this is the relevant snippets from my MyNewRangeWidget class:
      public MyRangeWidget(int min, int max, int tickSpacing) {
        super(new FlowLayout());
        slider = new JSlider(min, max);
        field = new JTextField(String.valueOf(max).length());
        add(slider);
        add(field);
        this.min = min;
        this.max = max;
        slider.setMajorTickSpacing(tickSpacing);
        slider.setPaintLabels(true);
        slider.setPaintTicks(true);
        slider.addChangeListener(new ChangeListener() {
            public void stateChanged(ChangeEvent evt) {
              if (evt.getSource() == field) {
                // change the value to the fields value
                // check for non-integer value.
                setValue(new Integer(field.getText()));
              } else {
                // change the field to the slider value
                field.setText(String.valueOf(slider.getValue()));
                if (slider.getValueIsAdjusting() == false) fireActionPerformed();
    and
      private void setSlider() {
        try {
          Integer i = new Integer(field.getText());
          setValue(i);
        } catch (NumberFormatException ex) {
          Integer i = (Integer)getValue();
          field.setText(i.toString());
          setValue(i);

  • CreateCDATASection() method doesn't creates a CDATA Section.

    Hi,
    While using Oracle XDK, if I try to create a CDATA Section using createCDATAsection() method, it doen't creates a CDATA Section. Instead it creates a normal Text node. If I try the same code with Apache Xerces, it works fine and I have CDATA section.
    The problem I am facing because, my node data has some special characters and I don't want parser to validate that. Has anyone else faced the same problem or have a work around?
    Any help will be appreciated.
    Thanks,
    Atif

    The double square bracket closing the CDATA section was never a problem. I had issues with LrXml encoding the opening angle bracket as an &lt; entity:
        local xml = LrXml.createXmlBuilder(false)
        xml:beginBlock("var")
        xml:tag("name", "var1")
        xml:beginBlock("value")
        xml:tag("string", "<![CDATA[value123]]>")
        xml:endBlock()
        xml:endBlock()
        local strXML = xml:serialize()
    Produces the following maligned XML:
    <?xml version="1.0"?>
    <var>
    <name>var1</name>
    <value>
    <string>&lt;![CDATA[value123]]></string>
    </value>
    </var>
    I guess one way to go about it is to run serialized XML through string.gsub to un-encode the "&lt;![CDATA[" sequence as follows:
    strXML = string.gsub(strXML, "&lt;!%[CDATA%[", "<![CDATA[")
    This is a nasty workaround, but this appears to be the only way to get the job done. Now my serialized XML looks as expected:
    <?xml version="1.0"?>
    <var>
    <name>var1</name>
    <value>
    <string><![CDATA[value123]]></string>
    </value>
    </var>
    This only leaves me wondering as to why LrXml doesn't support CDATA sections through its API, they are not that uncommon...

  • XML toString method not working as expected.

    Why is the XML.toString method inconsistant?
    var xml:XML = new XML( "<root/>" );
    var xml_withtext:XML = new XML( "<root>a</root>" );
    var xml_withchild:XML = new XML( "<root><child/></root>" );
    trace(xml.toString()); //traces "" (blank)
    trace(xml_withtext.toString()); //traces "a"
    trace(xml_withchild.toString()); //traces "<root><child/></root>"
    If the XML contains only a root node, toString prints nothing.  When it contains text, it prints the text.  That would make sense if toString was printing only the contents of the root node, but if the root node contains a child, it doesn't print "<child/>" as one would expect.  Instead, it suddenly includes the root node as well in the string.  That is inconsistant/unexpected.  For some reason, there is also a separate toXMLString method that consistantly prints the entire XML structure.  Was that some kind of patch since toString doesn't work in a consistant manner, instead opting to sometimes include the root node depending on whether it contains simple or complex content?

    Andrei1:
    1. No, it's not what it is.  No, there aren't hundreds of reasons/dependencies why more descriptive or intuitive conventions are not chosen. In this case, the reason (singular) is spelled out in the E4X spec, and it basically boils down to them naively thinking it would be easier for programmers if the node would just magically return text if that's all it contains.  In other words, they thought it would be simpler for a node to run specialized arbitrary logic to decide what to return, than it would for a programmer to explicitly select what they want by typing ".text".  I see no reason why XML.toString should return anything other than the underlying/original string of characters that originally represented the node in the first place.  If programmers wanted the child text of a node, they should call a method like "getTextContent".  Since an original, unaltered string of XML character had to exist in the first place in order to instantiate an XML object, anything that creates a new string based on arbitrary logic, for whatever reason, has no business existing within the toString method.  For classes that represent data that is not fundamentally a string, any string representation is by definition arbitrary and in that case they can override the universal (i.e. a member of every base Object) toString method.  But for classes that represent strings, toString should return the string they represent, unaltered.
    2.  An AS3 XML object IS an XML-type object, but the AS3 XML class is actually instantiated from String-type data or from  bytes that represent encoded String data (i.e. sequences of known  characters), because XML is very strictly and fundamentally a "markup language" which is essentially a format of a string of characters.  Its rules are based around characters, exact unicode character classes, and a logical ordering of those characters.  XML is logically and fundamentally the kind of data that a String class represents, text, so its converstion to a String instance should be straightforward.   As a string, a "toString" method for a node should return the original string representation of that node from the first character that is part of that XML node to the last character that is part of that node.  XML may contain data the represents anything, but XML itself is a string of characters.  Period.
    3.  There is a universal string method called toString and it's a member of the most basic class "Object" which all other classes inherit from.  Although the technical details are different in different object-oriented langauges, they all tend to have a method like that, whether we're talking about AS3, C#, Java, or JavaScript.  Calling toString on a String returns the string itself.  Calling toString on a class that represents a string, should return the string it represents; not some arbitrary tranformation of that string.  Calling toString on a class that doesn't represent a string, has no default string representation to return, and therefore any string returned is by definition arbitrary.
    4.
    In other words toString() does not return XML at all but an un-interpreted representation that is cast to String
    That's precisely what it DOESN'T do.  Instead of returning the original, un-interpretted representation of the string FROM WHICH THE NODE WAS CONSTRUCTED, it returns some arbitrarily interpretted represention.  It decides whether the XML string is interpretted as complex or simple content, and then it arbitrarily decides to include or not include the outermost tags representing the XML of that node.  The fact remains, the string representation PRECEDES the existance of the XML instance, so toString should not be performing arbitrary logic to construct a brand new string.
    In other languages datatype string can be a totally different animal.
    No, actually a string always refers to a secquence of characters.  Each of those character may contain one or more bytes, they may be contiguous in memory or not, they may be represented by arrays, linked lists, doubly-linked lists, etc. but their logical data is always a sequence of characters.  That is the same in every programming language, and is even codified in the Unicode standards which represents characters in hundreds of different written languages.
    5.
    Again, XML is not a string until application says so and XML in AS3 is not a String but a special object.
    XML is actually a string BEFORE the application says it is XML, since the XML is constructed FROM A STRING.  XML is a special object, which is constructed from, represents, and processes a string.
    I could very easily create a class named "AllCapsSentence" and like "XML", the class itself is not "String", but they logically represent a string of characters and any "toString" method on either of such classes should return the underlying string representation without mangling it.

  • Hiding inherited methods

    hi,
    I need to know how to hide a method from a subclass because it doesn't need it at all. I think using aggregation will solve the problem but how? do you have any examples regarding this please?
    For example, if the class Dog defines the properties "bark," "fetch," and "eat food" then a class Cat can be derived from Dog by hiding "bark" and "fetch" and adding "purr" and "sleep." And then "bark" shouldn't appear in the Cat class, is using aggregation solve the problem? by putting the class Cat as "whole" and class Dog as its "part".

    Poor design, poor use of inheritance. Cats aren't dogs, simple as that. This relationship is meaningless. Cat and Dog could be subclasses of Animal, which could have a method 'makeNoise' that both Cat and Dog could implement with their own noise. But a cat isn't a special kind of dog, so inheritance makes no sense here. Further, if you think something should be a subclass, but you have to find some way of getting rid of some methods from the superclass, chances are it isn't a subclass at all

Maybe you are looking for