It is invalid to have a data member or implemented property in a subclass with the same name as any PUBLIC or PROTECTED data member or implemented property in one of its super classes. This is true regardless of whether the data types of the two data members or properties match, because data members and properties share the same namespace. Thus, it is impossible to define data in a subclass that might override (shadow) or conflict with data in a super class without returning an error from the compiler.
Remember that this restriction applies to definitions at the level of the class. It is permissible to define a variable within a method that duplicates (and therefore shadows) a data member or property of the same name defined outside the method. Essentially, defining a variable in a method with the same name as a data member or property in the class hierarchy makes the data member or property invisible and directly inaccessible from within the method.
Note that you must override and implement any abstract properties in a non-abstract subclass that inherits them. However, if the inheriting subclass is abstract, you can, at your option, override any inherited abstract property and designate it again as abstract. The only difference you can make in creating a new abstract property definition is to specify a less restrictive access mode, overriding a protected abstract property to make it public. Note, again, that you cannot override an implemented property and make it abstract.
Note, also, that you can read or write any accessible property, whether it is abstract or implemented at the point of access. When you read or write an abstract property, you are always accessing the override that implements the property in the class hierarchy.
