Interesting question. My gut tells me not (as does three years of C# experience). I’m sure that everyone will have a different opinion on this but to me it seems taboo that a child class override the visibility of the parent class. For example, PHP currently does not allow you to override a method with a lower or higher visibility than the parent – I can’t go from protected to public or vice versa. Visibility must be maintained throughout the class hierarchy.
I realize that ten thousand people will curse up and down the first time they try to extend an internal class with a public one but good application design should be the real solution. >> Proposal (after five minutes of thought) >> >> >> 1. Public - A class can be instantiated or called statically from >> anywhere. For reasons of backward compatibility a class without any modifier >> would be considered public. >> >> 2. Internal - A class can only be instantiated/called from within the >> same root namespace. If I have a class Core\Mvc\View, only from within a >> class sharing the same root namespace (ex: Core\Html\Textbox) would I be >> able to access the "View" class. >> >> 3. Private - A class can only be instantiated/called from within the >> exact same namespace. Example, class Core\Mvc\View could only be accessed >> from a class in the Core\Mvc namespace (ex: Core\Mvc\Controller). >> >> What do people think? I'm not too concerned with the exact three I listed >> above, but more and more I think it would be wise if there were a way to >> restrict the accessibility of classes between namespaces. >> >> Jarrod Nettles >> Really like the general idea and think (IMHO) its RFC worthy, but have a few questions... Would there be any method of overriding the the visibility in a child class?And would the child class inherit the parents visibility? I realise this may seem daft initially but I can think of some instances where this might be useful. James Jarrod Nettles Application Developer - Technology INCCRRA p 309.829.5327 - f 309.828.1808 This e-mail message may contain privileged or confidential information. If you are not the intended recipient, you may not disclose, use, disseminate, distribute, copy or rely upon this message or attachment in any way. If you received this e-mail message in error, please return by forwarding the message and its attachments to the sender. INCCRRA does not accept liability for any errors, omissions, corruption or virus in the contents of this message or any attachments that arises as a result of e-mail transmission. Please consider your environmental responsibility before printing this e-mail
