method hiding with Private

for "Private" the manual states:

i have found that you can add Private on to the end of methods without causing a compile error.

Type privtest
	
	Method mytest:Int() Private
		Return 5
	EndMethod
EndType

it doesnt seem to have any affect when i Import the file though. i can still call mytest() from an instance of privtest and if i extend privtest, i can call the method there as well. does anyone know if this is supposed to work or has anyone accomplished type method/function hiding? hiding works fine with stand alone functions and hiding entire types.

i've been playing with this a bit myself.

i come from a very strong OO background, using Java for many years.

blitz's OO paradigm is _very_ confusing to me.

using your example from above.

i _think_ what you would find is, that if you were to add another method to your type, FOLLOWING the mytest method, that the "private" modifier would "carry over".

i think this is simply acting as a "switch" to the public/private mechanism in the Blitz compiler, rather than acting as a modifier for the method itself, which is what it _should_ be doing, imho.

i bought BlitzMax recently, over and above Blitz3D, because i really liked the enhanced language features.

when i played with the demo, before i bought it, i thought the "OO features" were quirky to be sure.

i guess i should have played with it more, because i am starting to find it a little more than quirky.

i think there are some things, such as this one, that are well intentioned, but are executed kind of poorly and are a nuisance to use, rather than being exciting and helpful.

but ... i still won't be kicking BlitzMax out of bed just yet ...

:)

Tony

I haven't messed with it much so don't get too mad if I'm wrong...

I don't think that doing something like Method test() Private should even compile. If you try to use the scope modifiers within a type decleration C++ style it won't compile. Perhaps it's only half implemented?

I've only seen them used in a 'global' manner to set the scope of the entire Type. I also think they can be applied to variables and free functions.

I will agree with you RktMan that the OO implementation is a bit funky. I think it's because BRL was trying to make everyone happy. Keep all procedural support, but introduce OO features that will encourage people to move to them instead of scaring them away. Also if this is to be fixed it's probably been left because it can be worked around without too much hassle.

Yeah. Private in BlitzMAX is a block style command, and not a traditional access modifier, as you might be acustomed too from Java or C#.

From what I understand BRL fully intends to add full access modifier support to BlitzMAX at some point. ATM though I think they pretty much have their work cut out for them with the upcomming GUI and 3D modules.

I think that's probably pretty accurate. More importantly, despite all the small annoyances, I think they found a good compromise.

Like Mikkel says, Private is currently block-style only:

Private

Type Oink
    Field x
End Type

Public

You can't yet hide individual fields or methods within a type, though something similar should be possible by extending a type:

Private

Type Oink
    Field x
End Type

Public

Type Oink2
    Field y
End Type

o:Oink2 = New Oink2

Print o.y
Print o.x

It's worth bearing in mind that BlitzMax was never meant to be a full OO language -- it's only meant to bring in [what Mark considers to be] the most useful OO features. (I'd still like to see hidden methods and fields myself though!)

Doesn't work. Anything inside the source file has access to the baseclass anyway, but if its outsife the source file it doesn't have access to any of the type so extending it wouldnt work.

thx for the response everyone. i tried Private at the end of the method as this is how the Abstract keyword is implemented. i was super excited when it compiled... and then suddenly listed hard to the right and fell out of the sky when it didnt work :) hopefully at some point this feature will be fully implemented, but until then, onward!

my main goal was create() functions in subtypes. without method or function hiding, you cant have a create function in a subtype whose parent has a create function unless the parameters are the same. many of the subtypes im working with have a different set of parameters than the parent... but the parent still needs its create function.

Good point... and I might have noticed that didn't work sooner if I'd remembered to extend the [beep]ing type as intended! Doh!

someone else, somewhere else on these forums did a posting that i am using pretty successfuly in my own code for hiding fields, which, as an OO person, is my #1 mission.

private methods being next in line ...

the sample i'm including shows how you can make a "Field" private, but provide an accessor for the "Field" as Public, allowing encapsulation of the attribute.

i'm writing this on the fly ... so grain of salt please ...

-- SNIP --

Private

Type TypeImpl extends TypeBase
Field field1:Int
Method GetField1:Int()
Return field1
End Method
End Type

Public

Type TypeBase
Method GetField1() Abstract
End Type

' return abstract type, created as concrete type in function
' the Field should be innaccessible outside of the source file
Function Create:TypeBase()
Return New TypeImpl
End Function

-- END SNIP --

yepp postet a little thing on that in the tutorial section "long" ago when we started with first modules and information hidding to prevent outside from messing with internal information.