error: class member is private in extended class

Monkey Forums/Monkey Bug Reports/error: class member is private in extended class

Skn3	(Posted 2013) [#1]

So I am pretty surprised if this hasn't been picked up so maybe there is a explanation for it that I missed?

If you create the following three files...

main.monkey

Import base
Import item

Function Main:Int()
	Local item1:= New Item()
	item1.Set(123456)
	Return 0
End

base.monkey

Import main

Class Base Abstract
	Private
	Field value:Int
End

item.monkey

Import main

Class Item Extends Base Final
	Method Set:Void(newValue:Int)
		value = newValue
	End
End

If you run this you will get an error:

ATTENTION: Compilation error reported by Trans: Field Base.value:Int is private.

However you get no error if you put this all in one file:

Function Main:Int()
	Local item1:= New Item()
	item1.Set(123456)
	Return 0
End

Class Base Abstract
	Private
	Field value:Int
End

Class Item Extends Base Final
	Method Set:Void(newValue:Int)
		value = newValue
	End
End

I tend to put each class in its own file which means its impossible to have private fields with a setup something like this:

entity.monkey
camera.monkey (extends entity)
tilemap.monkey (extends entity)

All fields are forced to be public if you want them to be accessible from an extended class.

A good example of a scenario where you would want to do this is if you were writing an API that provides both a high level access e.g.

myObject.SetName("object1")

or an override API for people to extend e.g.

Class BaseObject
	Private
	Field name:String
	Field x:Float
	Field y:Float
	Public
End

Class MyObject Extends BaseObject
	Method OnRender()
		' --- override so we can draw this objects id to screen ---
		DrawText(name, x, y)
	End
End

If name, x or y were set to private and MyObject was in a seperate file (pretty likely) then we couldn't compile. If we set name,x,y to public then we could lose the ability to do certain things like requiring that external access to the object goes through methods. The solution is properties, but isn't it slightly wasteful to add so many get/set function calls even when an object is processing internally?

The above, using properties would essentially be the same as:

Class BaseObject
	Private
	Field name:String
	Field x:Float
	Field y:Float
	Public
	
	Method GetX:Float()
		Return x
	End
	
	Method GetY:Float()
		Return y
	End
	
	Method GetName:Float()
		Return name
	End
End

Class MyObject Extends BaseObject
	Method OnRender()
		' --- override so we can draw this objects id to screen ---
		DrawText(GetName(), GetX(), GetY())
	End
End

It works, just doesn't seem as tidy/efficient.

ziggy

(Posted 2013) [#2]

No bug here. Public / private on Monkey is module (file) based, not class based. It would be very handy to have Protected attributes on classes, but that's another thing...

Skn3	(Posted 2013) [#3]

Ah right, it would be nice indeed. Whoops I am spamming the bug forum as usual then!

Gerry Quinn

(Posted 2013) [#4]

+1 for Protected access qualifier. (This was why I was asking why Node stuff is private in List the other day.)

Skn3	(Posted 2013) [#5]

Gerry ahh gotcha, thought you meant just basic access to node.