Perhaps, as they are the experts in this, you might want to give them a try. Your answer is the same as going to a DIY store and saying "I have a toothache, how do I get rid of it?" and when someone tells you to go see the dentist, you reply that if you'd wanted to do that, you would have, but your toothache is still there. Can you see how absurd the position is?
Basically, I agree, but it's important to understand: this is rationale, not the syntax rule.
Also, it does not address Bill's issue: actually, there is absolutely nothing wrong with having non-virtual method of an abstract class. I explained in my comment below why it is often be important.
All right, it's perfectly fine, I just took a note without any negative connotation.
Please see the comments by Richard MacCutchan and myself. I explained in detail why Bill's code is perfectly fine and safe (just updated).
You can "get away with it" because abstract classes can't be instantiated.
And because the concrete classes derived from it must implement both the setter and getter properties in order to compile, the abstract constructor can be guaranteed that the property is implemented in all instances.
So it's legal, and will work!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
It makes perfect sense. I just changed my comment to the wrong Mehdi's post and stated: abstract class is not a placeholder, not even close. I explained what it is and what is its purpose. And it should add: it should not be used as a substitute of interface.
Having non-abstract methods in an abstract class has more than perfect sense. Such methods are inherited and can be used in derived classes (so they should better be protected). Internal and public methods are even more important: the compile-time type of abstract class is usually used as a base class for some hierarchy of terminal derived classes used in polymorphic set. This is how you work with derived classed: through members of the base class. If such base class method uses virtual methods, late binging mechanism dispatch the calls to the methods of derived classes, so the whole OOP mechanism is leveraged.
There are many cases when this method in abstract class need not to be overridden, therefore, there is no a need to make it virtual or abstract (all abstract methods are of course virtual).
This is the very basic approach in OOD every developer should know and use.
Now, let me explain why there is no danger in your assignment of the abstract property in a non-abstract (and even non-virtual) method NoImplementations:
This is an instance method. As an instance method, it will need an instance to be called on. Such instance will always be an instance of some derived non-abstract type, because an abstract type won't allow to get an instance. And, such non-abstract type could not be created if SomeInt is not given the implementation. The mechanism of the late binding will use the virtual method table for the setter of SomeInt, according to the runtime type of that non-abstract derived type. Therefore, in all cases where NoImplementations can be called, the setter of SomeInt can also be correctly called and actually assign the property value. No problems whatsoever.
Of course not. But you decided to write and motivate your vote. You wrote, but not motivated, that's all. And you didn't understand the matter. Look, I don't have problem with you. But I would advise you to understand that everyone can read what you write.
So what? Do you understand that you have confessed in your own ignorance?
If some statement makes you feel bad, it does not make this statement false. Any objections? Only, please, on the matter of the subject under the discussion.
Sergey A Kryukov
Last Visit: 31-Dec-99 19:00 Last Update: 26-Nov-14 9:26