Disapproval for the missing of same-package access modifier

Discussions about Coding and Scripting
Post Reply
User avatar
PrinceOfFunky
Godlike
Posts: 1200
Joined: Mon Aug 31, 2015 10:31 pm

Disapproval for the missing of same-package access modifier

Post by PrinceOfFunky »

I hate it. No same-package access modifier for the variables. No way to avoid other packages to access your variables without setting them private.
Do you want your variable not to be modified by other packages? You can't :D Changing it to a costant doesn't work cause bypassable, setting it private won't let the classes of your same package to read/set it, using INT files won't let you modify those variables(also you would need to call Localize() from any class on that the file).
This is a disapproval cause it's driving me crazy, I'm writing code for the heatmap project since October, I'm not good yet into giving the right priorities to things, so I have worked on this project almost every day, those hacks helped me to bypass unrealscript limitations but it's late for this project, half of the code is made into unrealscript, next time I'll do a project I should use more external code than unrealscript, too many limitations. To clarify, you could be careless of limitations and write spaghetti code, but you know what would happen doing it, I take it too much seriously and become a perfectionist when making these projects, that's the biggest problem.

Also, anyone willing to create a json encoder/decoder for unrealscript?
"Your stuff is known to be buggy and unfinished/not properly tested"
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: Disapproval for the missing of same-package access modif

Post by Higor »

How's your C++?
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Disapproval for the missing of same-package access modif

Post by Feralidragon »

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.
User avatar
PrinceOfFunky
Godlike
Posts: 1200
Joined: Mon Aug 31, 2015 10:31 pm

Re: Disapproval for the missing of same-package access modif

Post by PrinceOfFunky »

Higor wrote:How's your C++?
Ah, I know what's your point, but I'm not that good at it yet, I would like to learn it but I'm not sure if it is that worth or not. I mean, I would need time to learn it and I know other languages which aren't that bad at almost-replace C++ in certain contexts, like Python can be used to write games on UE4 now, Python,Java and javascript can be used to write mobile apps and pc apps etc...
Feralidragon wrote: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.
And making those getters/setters finals, since another package's class could have replaced the entire reference to that class with a malevolent subclass of it.
Constant-like names become even longer when adding "class.get/set" and "()" at the end of the name, I have this costant-like name "CUMULATED_MATCH_INFO" which becomes "class.getCUMULATED_MATCH_INFO()", I mean it's a bit confusional.
Feralidragon wrote:without compromising things like control over your own classes
Yeah that's exactly the problem when you try writing something secure lol.
Feralidragon wrote:
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.
Time ago I found this: https://stackoverflow.com/questions/170 ... sing-class
But the one who replied said this:
the one who replied wrote:If you wish to write a parser, stop, think and then don't. It's a lot of work to get it working correctly.
Then I clicked the link to the official file-rules that explained how a JSON string/parser etc should have been: https://www.ietf.org/rfc/rfc4627.txt
That person tho still scared me, so I believe it would take a lot to build one lol.
"Your stuff is known to be buggy and unfinished/not properly tested"
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Disapproval for the missing of same-package access modif

Post by Feralidragon »

PrinceOfFunky wrote:
Feralidragon wrote: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.
And making those getters/setters finals, since another package's class could have replaced the entire reference to that class with a malevolent subclass of it.
Constant-like names become even longer when adding "class.get/set" and "()" at the end of the name, I have this costant-like name "CUMULATED_MATCH_INFO" which becomes "class.getCUMULATED_MATCH_INFO()", I mean it's a bit confusional.
Yes, making those setters final is also a common practice, I do it myself all the time.
But make no mistake, since you used the word "malevolent" there I will have to say something else on this regard: these are only meant to tell to whoever creates a dependency on your package that these properties are not meant to be accessed and that such methods are not meant to be overridden, and it only serves to avoid other programmers to extend something which is not meant to be extended, or manipulate something they are not supposed to manipulate, under normal circumstances.

When it comes to actual "malice", none of these will protect your package at all whatsoever. In many languages even things like private properties can be accessed and even modified, such as through "reflection" for example, since they were never meant for "security" to begin with, regardless of their naming ("private", "protected"...), they are only meant to establish how the code is organized and flow of control and what is meant to be exposed and extended and what isn't, when you declare something "final", this restriction can still be lifted in runtime if the programmer is really really really willing to in many languages.

Furthermore, don't forget that it's even more easy to just steal your code by then if one really wishes to modify things around.
PrinceOfFunky wrote: Time ago I found this: https://stackoverflow.com/questions/170 ... sing-class
But the one who replied said this:
the one who replied wrote:If you wish to write a parser, stop, think and then don't. It's a lot of work to get it working correctly.
Then I clicked the link to the official file-rules that explained how a JSON string/parser etc should have been: https://www.ietf.org/rfc/rfc4627.txt
That person tho still scared me, so I believe it would take a lot to build one lol.
I might be slightly biased since I already built parsers and tokenizers for several things, but JSON is actually relatively simple.
As you can see, the RFC for the JSON format is very small and easy to read through (check other RFCs on other formats for comparison, they're generally much much bigger), and even then there are pages dedicated to even make it simpler and more obvious on what you need to do.

Having that said, I do agree that reinventing the wheel may not be beneficial: if there's already a wheel that is good enough for your needs and has been thoroughly tested in production environments, you really ought to use that one rather than inventing a new one.
Which in this case, if you're going the C++ route, then I am sure there are plenty of good libraries, and integrating those libraries into UT is actually pretty simple (I already made things work like cURL, sqLite, multi-threading, etc, work in the past with UT without issues, and my knowledge on C++ is garbage at best atm), so you should just go ahead and use one of those, and just write the necessary code so you can interact with it through UScript.

However, the fact that you're probably going to use things like .int files to store these things, when going the C++ route you could write directly without any bs workarounds, tells me that you really want to keep it to UScript alone, and there's currently no good UScript library whatsoever to parse JSON, so someone has to build one first, it's inevitable, hence being in my plans to build one.

But now I just remembered that I have in fact built something already akin to a JSON parser, over 4 years ago:
http://www.mediafire.com/file/jr9e8wd9n ... eb_SRC.zip
I don't really remember how it works anymore, and since it's 4+ year-old code of mine, it's very likely to be garbage-tier by nowadays standards, but I do remember it working somewhat since I tested it with actual JSON APIs, so you might look into it if you want to check if there's something you can still use from there or not.
It also includes a more simplified HTTP client of mine, along with several hashing functions which do work well as far as I remember (MD5, SHA-1, SHA-2, ...).
User avatar
PrinceOfFunky
Godlike
Posts: 1200
Joined: Mon Aug 31, 2015 10:31 pm

Re: Disapproval for the missing of same-package access modif

Post by PrinceOfFunky »

Feralidragon wrote:However, the fact that you're probably going to use things like .int files to store these things, when going the C++ route you could write directly without any bs workarounds, tells me that you really want to keep it to UScript alone, and there's currently no good UScript library whatsoever to parse JSON, so someone has to build one first, it's inevitable, hence being in my plans to build one.
Well, "now" that we can call external scripts and write files using unrealscript, I guess json could be parsed elsewhere and then sent in a different format to unrealscript.
Feralidragon wrote:But now I just remembered that I have in fact built something already akin to a JSON parser, over 4 years ago:
http://www.mediafire.com/file/jr9e8wd9n ... eb_SRC.zip
I don't really remember how it works anymore, and since it's 4+ year-old code of mine, it's very likely to be garbage-tier by nowadays standards, but I do remember it working somewhat since I tested it with actual JSON APIs, so you might look into it if you want to check if there's something you can still use from there or not.
It also includes a more simplified HTTP client of mine, along with several hashing functions which do work well as far as I remember (MD5, SHA-1, SHA-2, ...).
Also, for the same reason I wrote above, an encoder could be written.
"Your stuff is known to be buggy and unfinished/not properly tested"
Post Reply