Why not finally allow bracket-less top-level keywords?

[Andrei Alexandrescu]

On 3/19/12 5:11 PM, deadalnix wrote:
> Le 19/03/2012 21:39, F i L a écrit :
>> deadalnix wrote:
>>> That is totally broken design. The fact that mothership inherit from
>>> ship is a pretty good example of misusing inheritance. The fireMissle
>>> is useless unless you KNOW that you are manipulating a MotherShip, so
>>> you totally break all the abstraction the OOP could provide.
>>
>> Other objects can contain references to MotherShip types directly, while
>> the main update loop works with the base type. Or, perhaps more
>> relevant, an object could execute "fire()" on a list of Ships, which
>> MotherShip can be a part of because it IS a Ship, regardless if weather
>> it can overwrite Ship's functions or not. I can't imagine a different
>> way of defining this relationship short of inheriting from a common
>> interface which would require duplicating the fire() function in both
>> types (given that fire() is designed to ensure common behavior among all
>> Ship types).
>>
>
> As all functionnality of a Ship are final, you basically ends up with a
> mother ship that is a ship and then have some other function that are de
> facto separated and unreachable from ship. Separation of concerns tells
> us that this should be 2 different objects.
>
>> This is not a broken concept at all. I'm always open to different ideas,
>> but I'm fairly surprised you're arguing this case. Being able to extend
>> a type, even when the extensions are entirely additive, is a fundamental
>> principle of OOP design.
>
> As teha ddition of MotherShip to Ship are orthogonal, I would argue that
> mothership functionality is better suited for its own
> class/struct/whatever, and agregated with a ship.
>
> The whole « is a » thing is largely misunderstood. See
> http://www.objectmentor.com/resources/articles/lsp.pdf for example.

I agree 100%. Inheriting to extend is borderline fallacious.

Regarding the matter at hand, it's true that the interplay of final 
class with final methods has an odd and less useful corner case, but I 
don't think it's worth worrying about it.


Andrei