Closed k-sareen closed 1 year ago
I generally prefer avoiding complex interactions between the superclass and subclasses and I like that subclasses aren't granted any special status as far as accessing private fields. It's maybe a bit jarring from the normal Java way, but I ran into too many mysterious and fragile interactions over the years to program in that style anymore.
That makes sense. It may be best to mention it in the documentation section about Inheritance then.
Added to the inheritance document.
As I mentioned in https://github.com/titzer/virgil/pull/117#issuecomment-1364495554, I personally find being unable to set
def var
fields from a subclass unintuitive. Is this a deliberate choice? If it is, can it and its reason be documented somewhere?Making a setter function is not a good solution, in my opinion, as you've now exposed the setter function to the rest of the world, defeating the purpose of having a
def var
field. Having asetLength(len: u64);
function for aVector
class just so a subclass can set the length sounds like a bad idea as now anyone using the baseVector
class can set the length (making thesetLength()
functionprivate
won't help as the subclass can't useprivate
methods either).