Jump to content
  • Advertisement
Sign in to follow this  
iraxef

Private class-member variables act like C++'s protected?

This topic is 1408 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement

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).

Share this post


Link to post
Share on other sites
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. Edited by rip-off

Share this post


Link to post
Share on other sites


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. smile.png

 


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.

Share this post


Link to post
Share on other sites
Disclaimer: I don't use AngelScript so I wouldn't advocate implementing anything just for my theoretical use case!

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites


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.

Share this post


Link to post
Share on other sites

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,

Share this post


Link to post
Share on other sites

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!

Edited by iraxef

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!