Lang design: shared members and inheritance

Community Forums/General Help/Lang design: shared members and inheritance

ziggy(Posted 2013) [#1]
How "going too far" would it look to you if a language that is designed to be strict and focus on easy to maintain applications disallows the access of shared members of classes from derived members. That is, shared members are not part of the inheritance "chain".
I think this would make things clearer and dissalow shared routines to "shadow" or "hide" ancestor's implementations. I think it makes no sense to allow overriding a shared routine on a derived class but, is it going too far? any thoughts or ideas where this could be a good idea?


Yasha(Posted 2013) [#2]
Not allowing static methods to be overridden seems like a "standard" OO feature (common to Java and C# at any rate), so it should be a safe enough rule to follow as most users will be expecting something like that to be the case.

That doesn't seem like an unreasonable suggestion at all. I for one can't offhand think of any real use case for needing to access a static method through an inherited class. It's static, that's the point; they should know what they're trying to call.

Besides, the current fashion in OO is to discourage deep inheritance, and instead focus on wide, shallow class families implementing common interfaces instead. Reducing the amount of stuff that can be automatically inherited would encourage the user to build a shallower class hierarchy. So, useful for stylistic strictness as well.


ziggy(Posted 2013) [#3]
@Yasha: Thanks. I'm really going to add interfaces to my language at some point for sure. It's a must but I want to get classes right first hehehehe, it's HARD!
Also, the way you can access a shared member prefixing a child class, not sure I like that too. Anyway, if it does not look weird, I'll go for it