This is just me, but I think private properties is all that you actually need most of the time, and therefore should use them 99% of the time.
I don't think that any other class, or even subclass, should just go ahead and modify a property at will, even when belonging to the same package, because that automatically breaks isolation and behavior awareness across different classes, and it means that from there on you have absolutely no idea at any point in time which objects, including your own, are modifying which properties, and when, so you no longer have any control over them.
There are a few things I miss in UScript, which were only introduced in later engine versions, such as private and protected methods, ternary operators, and such, although this is something that could still be made through a new compiler, which I am not going to lie, it has actually already crossed my mind in building one (something akin to what TypeScript is to JavaScript, what nowadays people call a "transpiler"), although I am not even going to look into doing one for a very long time, maybe ever, depending on how far I can actually go with other things.
Either way, after making your properties private, if you wish to have a property to be "modifiable" to any extent, you just create a setter method, simple, just like you would do in any other OOP language.
If in other languages you are relying on the "same package access modifier" mechanism some of them employ, your code will still be spaghetti in the end.
From there, if you really want to have as much control as possible over your own code, even considering other packages depending on your code, you should adopt the proper design patterns which enable you to do so, such as segregation, proxy, facade, factory, strategy, etc, or simply by following SOLID principles over all.
For instance, in my own PHP framework I have "components" (the class is literally called "Component"), however each component holds a "prototype" (also called "Prototype"), and the component is what is exposed outside and is used, however the prototypes define specifically how the component will behave internally, and is "hidden" from outside.
To give you a quick example, one of my components is an Input, and as an input, you're able to use it to set and get a value, which is internally validated and sanitized, and you're also able to retrieve information such as a label, a description, error message, those sorts of things, and is mostly meant to be used to dictate field types in APIs, forms, etc, establishing a hard-typed interface, hence making the whole thing inherently secure.
Then, there's the input prototype, which actually implements internally how a value is validated and sanitized, and which label, description and error messages to actually return specifically, so then I have a number prototype, text prototype, etc, and although prototypes have public methods, they are only used by the component itself internally, they are never meant to be used outside, prototypes are in fact useless on their own without a component, because in the end they are just templates and do nothing on their own other than returning stuff from their public methods.
So this way I get to be able to set public methods for prototypes (especially useful to segregate into interfaces and for potential unit testing later on), but still hide and abstract it completely from the actual usage, and a component can evolve independently from a prototype, so if you need to subclass a component for any reason (such as to define a new method to be used), you can still use the same prototypes.
In other words, what you actually need to do is come up with a strategy, or use an existing one (design pattern) on how you model things overall so they help you to actually achieve what you want to build, in the easiest way possible, without compromising things like control over your own classes for example, which seems your primary concern.
PrinceOfFunky wrote:
Also, anyone willing to create a json encoder/decoder for unrealscript?
It's within my own plans to do so, as I am going to need it too, but it won't probably happen for several months, maybe a whole year even before I even look into doing it.