Re: why is a superclass allowed to access protected methods of a subclass?

From: Woebegone (woebegone_at_cogeco.ca)
Date: 12/14/03

  • Next message: WJ: "XHTML & javax.swing.text.html" 
    Date: Sun, 14 Dec 2003 01:25:35 -0500

    > 4) a number of people have explained/justified the behaviour in terms of
    > polymorphim. I disagree - in my opinion, - encapsulation is a compile
    time
    > issue - its about the compiler enforcing rule of visibility - so it's
    > determined by the object's static type and its package. Polymorphism is
    > purely a run-time thing - not the realm of the compiler at all. It seems
    to
    > me that fact that the compiler allows access to a protected method on an
    > object outside the pacakge is an odd exception to the general rule, and
    the
    > fact that the subtype is a related type is not a strong enough reason to
    > justify it.
    >
    >
    Hi Pat,

    I think you've raised a very interesting question, and I have to admit I was
    surprised to learn of the package visibility of protected methods. In C++
    terms, it's like package colleagues are friends -- I though encapsulation
    would dominate.

    But, consider the case where a superclass declares an abstract method, then
    calls it as in a factory method as mentioned earlier. Any concrete subclass
    must provide an implementation of the method, so the superclass knows a
    priori it's there at runtime (this is a runtime rule inferable at compile
    time). The code that executes will be that of the runtime object's class:
    this is why I said earlier that the superclass implicitly can access the
    sublass's implementation.

    Then, we know in Java that it's impossible to call up the hierarchy to
    arbitrary depth: it's "this," or "super." As an earlier poster mentioned, no
    class can infer at which level a member is implemented.

    So, I think that the compiler has to behave the way it does to accommodate
    polymorphism, while doing what it can to enforce encapsulation. Polymorphism
    is a runtime thing, but it requires compile time support.

    Protected access supports polymorphic hierarchies; package access is, as I
    see it anyway, a pragmatic violation of encapsulation.

    Regards,
    Sean. 

    ---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.548 / Virus Database: 341 - Release Date: 05/12/03
  • Next message: WJ: "XHTML & javax.swing.text.html"

    Relevant Pages

    • Re: Freeware download corrupt (?)
      ... > a list of all functions in a package that fall in that category. ... > conflict with a function of that name in a future version of the CRTL. ... > But the compiler doesn't do that, so for now we're on our own. ... I create a package with a routine in it called "highwater". ...
      (comp.os.vms)
    • Re: PL/I, COBOL, Advantages, Equivalence, et al
      ... SPARK will allow a variable to have a value that conforms ... might be that a package somewhere will look like this ... An Ada compiler may issue a warning; ... LC> Ada/SPARK support a boolean type? ...
      (comp.lang.pl1)
    • RE: Visual studio 2003 .NET versus its own Command Prompt
      ... > package in the lab. ... > command line compiler which cames with it. ... library, which is a .lib file, for it to know where in the DLL the functions ...
      (microsoft.public.vc.language)
    • Re: Frage zu Packages und our
      ... Der Compiler selbst schaut jedoch bei einem unqualifizierten ... Laufzeit tatsächlich auf die globale (Package) Variable zugegriffen. ... von "my" ident sind - denn ein innerhalb eines Scopes deklariertes ...
      (de.comp.lang.perl.misc)
    • Re: How to use packages?
      ... libraries in assembly could be created and imported for use. ... package so that some very cool libraries could be created in ways that I ... This would be very wrong -- basically giving away a Lisp compiler ... For example (given the name as.exe for the assembler): ...
      (comp.lang.lisp)
    Loading