Isn't this supposed to not compile, let alone run ?

Started by Captn. Jinguji, October 13, 2021, 12:51:05

Previous topic - Next topic

Captn. Jinguji

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

markcwm

Hey Captn,
well it wouldn't compile on Blitzmax vanilla/BRL but I don't see why not on the latest NG.

Captn. Jinguji

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?

markcwm

Hi Captn,

OK sorry about my poor English, yes I meant that NG should actually compile this as it does.

Captn. Jinguji

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 ...

markcwm

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?

Captn. Jinguji

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. 

TomToad

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.
------------------------------------------------
8 rabbits equals 1 rabbyte.

Henri

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):
Code (blitzmax) Select

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
- Got 01100011 problems, but the bit ain't 00000001

Captn. Jinguji

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