Private functions are unnecessary

[stugol]

I have always thought that sealed was a goddamn stupid keyword in any language - e.g. C# or Java. Why for the love of god arbitrarily prevent the programmer from inheriting the class?

Similarly, I'm starting to question private. What benefit is there in restricting what a derived class can access in its base? When you write a derived class, you by definition are expected to understand the workings of the base class; and are intending to modify its behaviour.

Onyx, like Ruby and Crystal, is a monkeypatching language. As such, it has even less reason to impose encapsulation restrictions on class subtypes.

I propose that private and protected be conflated. There is no benefit to distinguishing between them. Use a single asterisk, call it private, and have it behave like protected.

[ozra]

sealed - agree completely, especially as you mention, the monkey patching perspective. I can imagine a wordy 'dont-override for methods where one should think twice and requiring 'redef to override them. Just to make the coder think twice. But not a definite sealed/final "prohibition" - that's just ridiculous.

I earlier experimented with the opposite: more levels of visibility (with changed names like internal, family, etc.) but as you see, they did not end up in the language ;-), and I'm prepared to agree with you.

The problem arise when you want to override methods from a crystal library you include, then it's needed to be able to match the semantic meaning in the crystal sphere also in Onyx code.

In any event, it occurs to me that the meaning of * vs ** should probably be switched out, makes more sense. * means Protected. But the visibilities should have a different name in Onyx terminology still (when documenting it), since otherwise it's just an asterisk. "Protected" is far from clear in its' meaning.

[stugol]

* means Protected

Do you mean it currently means protected, or it should mean protected?

I think Onyx shouldn't have a private specifier at all. Surely I can override a private Crystal method without specifying "private"?

Probably call protected "internal", to avoid confusion from calling it "private".

[ozra]

Yes, it should be protected.

I don't think it hurts to keep the double asterisk for private should someone really need it. It's uglier so hopefully it's avoided ;-) (after I reverse them to the "should be"...)

[ozra]

Fixed.