Hello, folks.
SuperStrict
Type TCounte
Private
Field value:Int
Protected
Method Increment()
value :+ 1
End Method
End Type
Local cntr:TCounte
cntr = New TCounte
cntr.value = 49
Print cntr.value
cntr.Increment()
Print cntr.value
Fresh Install of a fresh download of Blitzmax from blitzmax.org
Result:
Building 222
[ 98%] Processing:222.bmx
[ 99%] Compiling:222.bmx.gui.debug.win32.x86.c
[100%] Linking:222.debug.exe
Executing:222.debug.exe
49
50
Process complete
Hey Captn,
well it wouldn't compile on Blitzmax vanilla/BRL but I don't see why not on the latest NG.
Hey Markcwm.
Sorry for not being good at the double negation game. ;)
Are you stating that NG should actually compile this as it does,
or rather, that you can't determine why NG is letting this happen?
Hi Captn,
OK sorry about my poor English, yes I meant that NG should actually compile this as it does.
Hmm...
so, "Private" and "Protected" keywords (and likewise "Public" ) have become obsolete,
together with the corresponding passage in the OO Tutorial. ...
Not so good, I think....
Thanks anyway for clearing this up ...
Oh I see yes, going back to BCC 0.92 the private field produces the compile error 'field is private' and the protected method also errors with 'method not found'. In BCC 0.129 it compiles and runs without error.
Looking up the difference, as I can't remember! I find protected is only accessed by the class and inherited classes, and private only by the class itself.
But I'm confused, isn't 'cntr.value = 49' actually OK? Because you're accessing it from 'cntr:TCounte' that should be OK right, it's the same class. Or can private only be accessed inside the class itself?
Hi, Mark.
No,
cntr.value = 49
outside of the corresponding Type is only ok when cntr.value is "Public" (which is the default).
Imagine cntr.value representing a value crucial for internal mechanics of a type, or a sensitive value like a Person's ID.
I am well aware that most likely, there are no nuclear plants or hospitals running BMAX programs in crucial environments. But the exact same statements "private, ..." are there in C++, and they were alredy in place and operational in former BMAX versions.
Yes, BMAX is free, maintaining a compiler is probably a lot of work, and possibly few people make use of those keywords, but I'd rather have them removed or a compiler warning tied to their use at the very least, so a developer is not relying on the level of safety they suggest, when it is totally not there.
It was actually an (un)lucky find that I spotted this predicament; I was a BMAX user way back in time, found out now that it is still in existence and under some kind of maintenance, looked at the OO tutorial to see whether there was any progress there - and picked the exact offending example - call it serendipity, if you want.
The case is more or less similar to internally blocking 'strict' and 'superstrict' behind the developer's back; programs will run without them, but a lot is compromised without them being able to kick in when necessary.
If I'm not mistaken, I do believe that BMX-NG doesn't have private or protected in the traditional sense. The keywords are only relevant in modules to tell the compiler which fields and methods are exposed to importing programs.
Hi,
according to Blitzmax documentation Private 'hides' the member/variable from outside the source file where the variable was declared private. I think this was intended for global variables that are defined in a source file containing your API for example, so that you don't have to worry about variable naming interfering with other program elements.
Good example of this is a counter (and I use this a lot):
Private
Global counter:Int
Public
Function GetNewID:Int()
counter:+ 1
Return counter
EndFunction
When you import this source file in your project you don't have to worry about using counter as a variable name in your main file, as this is quite common name for variable.
I haven't used protected so I'm not sure what is the difference there (other then documentation stating that it can allow subtype to access the protected member)
-Henri
Thanks, Henri & Tom Toad.
Guess you are right, since the offical documentation puts it the way you do, as I saw now - it was just that the tutorial from blitzmax.org - which is quite apt otherwise, btw - has it differently. ;) (see quote below )
Nevertheless, it's clear now, terminally.
Thanks to all
In the code above, all Type members are publicly accessible to all parts of your program. We'll now prevent direct access to the member variables:
SuperStrict
Type TEntity
Private
Field x:Float, y:Float
Public
Method Draw() Abstract
Method New(x:Float, y:Float)
Self.x = x
Self.y = y
End Method
End Type
Type TPlayer Extends TEntity
Private
Field health:Int
Public
Method Draw()
SetColor 0, 0, 255
DrawOval x, y, 5, 5
End Method
Method New(x:Float, y:Float, health:Int)
Super.New(x, y)
Self.health = health
End Method
End Type