I just started getting into AngelScript a few days ago (love the library!) and have begun work on adding a few language extensions for purposes of encapsulation-- you're welcome to them once I finish. Specifically, I'm attempting to implement private functions/member variables that can only be called from/accessed within the object itself. I have the keyword(s)/tokens functioning, but am getting a little stuck regarding the specifics of implementation; can I get some more information on the asSExprContext fields? So far it just looks like I need to add a new 'is private' flag to the property description struct but I also need to get a handle on what information is available to me via the calling context in order to check if the request should be denied.

Actually, scratch that, a trip through the debugger managed to make everything fall into place. If you'd like, I can try and get a set of file diffs all packaged up and you can make this extension official :) The only catch for now is that I need to rework a few aspects of application-side property registration so as to have the privacy attribute set correctly. As it stands, only script-created classes/properties will interpret the token. Inheritance, etc. works fine and this shouldn't break any existing installs.

Cool! I'd very like to see this enhancement. Though I'd prefer if you send me the modified files rather than the diffs. I find it easier to work with WinMerge, rather than diff patches.

Ok, finalized the last few details and decided to add some helper functions to the binding interface; this seemed much more elegant than having the user tack 'private' before the declaration in the object property registration function. I also added support for this concept in the bytecode save/restore utility classes for consistency's sake. Is there any particular method you prefer for sending the modified files?

At time of writing there are still a few more quirks (really just questions of 'do I need to verify visibility here' rather than 'this breaks things') that bear further thought. You might also consider making the new token 'protected' instead of 'private' as this more closely matches the C++/Java term for visibility semantics. As it stands, subclasses can freely access the property/getters/setters. Further thoughts appreciated and I'll probably look into implementing 'final' methods and classes next.

EDIT: I forgot to mention that I moved the class derivation/interface implementation query functions into asIObjectType; I used these for visibility checks and think they would probably be useful for library users anyway.

You may send the files to my e-mail: andreas@angelcode.com.

I'll take a closer look at your changes and see how I easily I can incorporate them into the library. Though, I'm sure it shouldn't be too difficult.

All right, mail is sent. Either drop me a line here or reply if you run into any difficulties with getting this to work properly and I'll see what I can do for you.