The story behind Private and Public?
BlitzMax Forums/BlitzMax Programming/The story behind Private and Public?
| ||
Why is is that Private and Public doesn't work with Types? Seems like such an simple thing (though nothing ever is). Anyhow it would be really handy, both when making modules and especially, as I'm doing now, coding using IntelliSense. Anyone who knows the story? |
| ||
Why is is that Private and Public doesn't work with Types? It doesn't? |
| ||
It doesn't? I should suspect he is trying to do something like encapsulation and hide certain fields and/or methods. In such a context, e.g., within types, it doesn't work.Strict Type Foo Private Field m_a:Int Public Method a:Int() Return m_a End Method End Type Above will not compile. |
| ||
I should suspect he is trying to do something like encapsulation and hide certain fields and/or methods. In such a context, e.g., within types, it doesn't work. Oh, well I was thinking wrapping an entire type as private. :) |
| ||
That for sure would be a nice feature. I know my game would crash if quite a few "private" variables within types were modified manually. |
| ||
When using an ide like BLIde you can add a block like this: Rem bbdoc: DO NOT TOUCH THIS End Rem Field m_ptr:Byte Ptr That way when you're using intellisense it'll show up, reminding you not to touch it :-). |
| ||
This can't be a new idea (maybe even part of the reason for private in the first place), but I just did a test with a public type that has it's member data locked up in a private type and it works well. SuperStrict Module foo.privatetypes Private Type fooPrivate Field iX:Int Field iY:Int Function Create:fooPrivate( iX:Int, iY:Int ) Local n:fooPrivate = New fooPrivate n.iX = iX n.iY = iY Return n End Function End Type Public Type fooPublic Field foo:fooPrivate Method SetX( iX:Int ) foo.iX = iX End method Method GetX:Int () Return foo.iX End Method Method SetY( iY:Int ) foo.iY = iY End Method Method GetY:Int () Return foo.iY End Method Function Create:fooPublic ( iX:Int, iY:Int ) Local n:fooPublic = New fooPublic n.foo = fooPrivate.Create( iX, iY ) Return n End Function End Type SuperStrict Import foo.privateTypes Local pvt:fooPublic = fooPublic.Create( 200, 100 ) pvt.foo.iX = 20 ' will not compile! Print pvt.GetX() Print pvt.GetY() pvt.SetX( 1 ) pvt.SetY( 99 ) Print pvt.GetX() Print pvt.GetY() I'm not a fan of Getters and Setters blindly replacing public members but they are useful if they are doing more than in this example (bounds checking etc). |
| ||
@matibee: This is how the fontmachine module is done to encapsulate public and private members and it works like a charm. It is like making a wraper, creating an public 'interface' for the private member. |
| ||
While that is a solution, it's a hacky solution. I'd prefer not to have to use hacks to do something. |
| ||
@Nillum: Of course. |
| ||
@Htbaa, hehe yeah that's a creative work-around^^ @matibee, yeah. I have thought about re-factoring some more sensitive code to work like that. Like said, its a bit hacky. For a module it could work pretty good, especially if it is an non-opensource module. Users are only going to be aware of the variables/fields/methods you tell them about, but when it comes to opensource, private would be nice and (especially with the help of intellisense) make the code cleaner, since non-public stuff would not show up. What do you think the original reason for it to not work "as expected"? Anything that could be "fixed"? |
| ||
Just put an underscore at the beginning of any member that you intend to be private and anyone crazy enough to change it can deal with the consequences. Problem solved. Note that this is how Python works and it doesn't seem to cause them any problems at all. |
| ||
Even in languages that do support private or protected fields lots of people prefix them with an underscore. I do so as well. It's very easy to recognize. |