• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Redeclaring overrides
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Redeclaring overrides


  • Subject: Re: Redeclaring overrides
  • From: "John C. Randolph" <email@hidden>
  • Date: Sun, 19 Aug 2001 11:55:05 -0700

On Sunday, August 19, 2001, at 08:35 AM, Ondra Cada wrote:

John,

John C. Randolph (JCR) wrote at Sun, 19 Aug 2001 02:27:34 -0700:
JCR> I usually declare overrides in the header, just because it helps anyone
JCR> reading my code to quickly see what I've changed from the superclass.

Well, there's also a different approach (which I happen to admire) that
nobody who wants to use or subclass my code has right to know which exactly
I've changed or not outside of documentation's scope.


You know, it's called "ecnapsulation".

I call it "obstruction of maintainability." It's fine and dandy if you're always going to be the maintainer of your code, but for many others that is not the case.

The thing is that I might want to
override some other methods in future without changing the API (just, say,
fixing some bugs).

It is quite possible that my way of doing that would not
change the behaviour of those reimplemented methods, but the behaviour of
others!

How is this inhibited by declaring overridden methods?

-jcr


[Objc retain];


  • Follow-Ups:
    • Re: Redeclaring overrides
      • From: Ondra Cada <email@hidden>
References: 
 >Re: Redeclaring overrides (From: Ondra Cada <email@hidden>)

  • Prev by Date: in-memory files?
  • Next by Date: Learning Cocoa: Dot View
  • Previous by thread: Re: Redeclaring overrides
  • Next by thread: Re: Redeclaring overrides
  • Index(es):
    • Date
    • Thread