How do get PRIVATE methods/fields for real!
BlitzMax Forums/BlitzMax Programming/How do get PRIVATE methods/fields for real!
| ||
There are various workarounds and alternatives out there for the fact that BlitzMax doesn't have proper OOP private members, but all I've found suffer from a fatal flaw - they can be circumnavigated. I've devised an ingenius way to properly protect methods and fields of objects that can't be circumnavigated through ordinary use of code.Strict
Import "object.bmx"
Local p:pu = new_priv()
p.set_name("Alfred")
Print p.get_name()object.bmx Function new_priv:priv() Return New priv End Function Type pu Method get_name:String() Abstract Method set_name(n:String) Abstract End Type Private Type priv Extends pu 'private variable Field name:String Method get_name:String() Return name End Method Method set_name(n:String) name = n End Method End Type Outside of object.bmx, there is NO way to access the field of name. I challange you to find a way! You cannot even cast to priv! You must use the getter and setter methods. This only works if you import the file. If you include the file, it doesn't prevent it, unfortunately. |
| ||
| this information has been on the boards for at least 5 years... 4 yr ago http://www.blitzbasic.com/Community/posts.php?topic=49883#554675 5 yr ago http://www.blitzbasic.com/Community/posts.php?topic=42469#475740 sorry... |
| ||
| Darn. Well, I felt clever for a day :( I know others think this is nitpicking, but I really need public/private for my project. My supervisor is big on OO and might not appreciate the hidden beauty of these hack-methods. |
| ||
| if you can get him to accept BM at all, he shouldn't play asshole for this trick (or plan simply using a clearly documented notation like starting m or _ ) |
| ||
| She doesn't know I'm using Blitz yet ;) At the moment I'm using the idea I stated above. Do you think it looks unprofessional? Has anybody used it in a real project? I have to provide at least some trivial evidence I have conformed to accepted coding standards and conventions. (Yes, it's an academic project) |
| ||
| I used it in projects back then yes (closed source modules where I wanted to prevent users from messing it up). I've since then come up with a different way to do it that does not disable any possibility for inheritance. I personally would go with coding guidelines and mark private field accordingly (in BM the standard is _blabla for private field blabla) and follow it from start to end. That will give you less headache and you show more respect to coding standards than with this inheritance breaking approach (you can only use the decorator pattern with this "private fake") |
| ||
| I've since then come up with a different way to do it that does not disable any possibility for inheritance. But the way Czar Flavius is suggesting does not break any possibility for inheritance. It's just a private class and a public class that acts like a wrapper and this class can be inherited as any other class, in fact, even the Private field can be shadowed by inheriting classes, so not really an issue IMHO. |
| ||
| it breaks it. His / my solution bases on a hidden private class that inherits from your public class. if you extend the public class all hidden implementation is gone. you would have to extend the hidden class which you defacto can't do. Unhappily you can naturally not mark the public class as final either as the hidden would be invalid too. these problems are the reason why I stopped using it and first went with the regular Blitz "private field" notation (_yourVar) until I later started to sort the code and declarations in the right order to make private stuff private by simply postprocessing the .i file |
| ||
| later started to sort the code and declarations in the right order to make private stuff private by simply postprocessing the .i file What's this? |
| ||
| if you extend the public class all hidden implementation is gone. Why? I'm using it all the time without any problems! |
   |