Encapsulation bug
Monkey Forums/Monkey Bug Reports/Encapsulation bug
| ||
This should not compile:Function Main() Local a:= New Stack<MyClass> a._Swap(10, 20) End Class MyClass End _Swap(x, y) is private but we can access it. EDIT: Updated as the sample I got was not a valid example in latest Monkey version |
| ||
| This changed recently and deliberately. I believe it's so you can implement your own extending map or showing algo,I forget the exact reason. |
| ||
| Changed in v78g ***** v78g ***** Made FirstNode, LastNode public in Map. |
| ||
| Well, take any other private method on any other module and the bug is the same. Better sample: Function Main() Local a:= New Stack<MyClass> a._Swap(10, 20) End Class MyClass End |
| ||
| Not sure when that crept in...will fix. |
| ||
| Thanks! It's very appreciated |
| ||
| I was under the impression that the Private directive only worked for fields, as I never saw it work for methods. I keep most methods private anyway, as a matter of discipline[*]; if it's fixed I'm happy about that. But really what I'd love to see is a Protected directive. Protected fields and methods would be public to sub-classes, but private to all others. Looked at that way, it shouldn't be too hard to implement. Maybe Mark has a philosophical objection to it (I know some people do) but a lot of us would definitely be in favour, and the rest don't have to use it ;) [*] You may well ask: "if it doesn't actually work, at least not lately, what discipline applies?" The answer is that in every class is an empty function called ______Private_______:Void(), and the methods coming after it in the coding window are not considered permissible to call from other classes. (If my IDE could auto-detect private methods, of course the function wouldn't be needed, but it works well enough anyway.) |
| ||
| Public and Private lie in the global scope don't they? I don't think a Protected feature could be added because of this. |
| ||
| Private fields and methods are usually private for a reason. I've changed the inner nuts-and-bolts of some of the Diddy classes many times that would have broken other people's code if I'd made them public. Encapsulation is a wonderful thing when used correctly. |
| ||
| Say you want to extend monkey.List and do something interesting involving nodes. The node structure is very unlikely to change, but there is no direct way to get at it. I support encapsulation in that the internals of List should be invisible to unrelated classes. But not being able to access them in sub-classes is inefficient. Private would remain as an option - one could choose whether private or protected is more appropriate for a given situation. |
| ||
| If we are going to discuss encapsulation, my go would be very different. I would allow for friend members where a module can expose class members only to the modules it is importing. Say you do a Module X that imports several submodules, it could be very handy to allow them access the required internals stuff, and at the same time, external usage of that module, would still be protected. That would allow us a much better modular encapsulation system IMHO. I'm a bit philosiphically agains protected modifier, but that's maybe just me. |
| ||
| If we are going to discuss encapsulation, my go would be very different. I would allow for "friend" members where a module can expose friend class members only to the modules it is actually importing. Say you do a Module X that imports several submodules, it could be very handy to allow them access the required internals stuff, and at the same time, external usage of that module, would still be protected. That would allow us a much better modular encapsulation system IMHO. I'm a bit philosophically agains protected modifier, but that's maybe just me. |
| ||
| To me, that seems back to front! List doesn't know that you are going to make a derived class that will need access to its fields. Of course if you could use a friend keyword in one module to force access to private fields in another module, that would work, though it doesn't seem very friendly! |
| ||
| To me, that seems back to front! List doesn't know that you are going to make a derived class that will need access to its fields. Yes, encapsulation is meant to encapsulate implementation details, that's why I'm against "protected. But I find it useful to allow "public inside my framework" that is also "private outside my framework" so you can have internal implementations subject to change, while you keep a transparent usable interface to your framework users, without having to use _ prefixes, or making huge files to group private things in a single document. Of course if you could use a friend keyword in one module to force access to private fields in another module, that would work, though it doesn't seem very friendly! |
   |