Could you please add something to the documentation to clarify the behavior of private base-class-member variables in derived classes? It seems that there's no way to preclude derived classes from accessing a base class' private members? Could the final keyword perhaps be extended for this use-case?

Thank you!

-snip- I'm an idiot: didn't see this was AngelCode

I'll update the manual to clarify the meaning of private members.

Do you really need to prevent a derived class from accessing the base class' member? Can you give a useful example of this so I can consider the worthfullness of implementing it (maybe even change the meaning of 'private' and include 'protected' to be more in line with C++/Java/C# etc).

Allowing a child class to access any data in a parent class allows the child to potentially break invariants the parent wants to establish. In particular, under changing requirements the meaning of data in the parent may change, which if always exposed to every child increases the area of the code at risk of breaking from the change. Having an intermediate level allows the parent to control the data and functions it grants the child privileged access to, while continuing to enforce invariants but not exposing too much to the wide world.

I'm not sure this is quite as useful for a "scripting" language than one intended for building large scale systems. However a potential use might be a modding API, where the game engine might provide some helpful parent classes but needs to maintain a certain amount of hidden state / behaviour in the script side - stuff that can be freely changed / removed between versions without breaking client code.

I'm not sure this is quite as useful for a "scripting" language than one intended for building large scale systems.

This is exactly my point. Many of the design decisions I take for AngelScript are based on the fact that it is a script language, and not really meant for large scale standalone programs. I'm not trying to recreate C++ in scripting form.

However a potential use might be a modding API, where the game engine might provide some helpful parent classes but wants to maintain a certain amount of hidden state in the script that can be freely changed between versions without breaking client code.

This makes sense.

Disclaimer: I don't use AngelScript so I wouldn't advocate implementing anything just for my theoretical use case!

Disclaimer: I don't use AngelScript so I wouldn't advocate implementing anything just for my theoretical use case!

You covered my use-case pretty nicely :)

Disclaimer: I don't use AngelScript so I wouldn't advocate implementing anything just for my theoretical use case!

Too late, Andreas already implemented all the ideas for all your theoretical cases.

I've corrected the meaning of private class properties in revision 2098. Now a derived class cannot access the private properties of the base class,

I've corrected the meaning of private class properties in revision 2098. Now a derived class cannot access the private properties of the base class

Since this has backwards-compatibility implications, would you consider making this the new default, but adding an engine option to make old behavior an error or to emit a warning?

Thanks!