Is it possible to restrict access on structure fields?

[jacdelad]

Hi,
is this possible? Let's say I have a Structure, defined in a module:

Code: Select all

Structure Gerber
  Identification.q
  BoardSize.Pos;in mm
  DrawScaling.f
  Unit.a;mm/inch
EndStructure

...and I want to prevent the programmer from having access to the DrawScaling variable outside the unit. Is this possible? Or do I need a second structure which is completely put inside the module and a mapping/assignment mechanism inside the module? I hope I can express my question correctly...

[Cyllceaux]

I have some Ideas:

Idea 1:

Code: Select all

DeclareModule Test
	
	Structure Pos
		X.i
		Y.i
	EndStructure
	
	Structure Gerber
		Identification.q
		BoardSize.Pos;in mm
		Unit.a			 ;mm/inch
	EndStructure
	
EndDeclareModule

Module Test
	
	Structure InternGerber Extends Gerber
		DrawScaling.f
	EndStructure
	
EndModule

Idea 2:

Code: Select all

DeclareModule Test2
	
	
	Interface Gerber
		GetIdentification.q():SetIdentification(value.q)
		GetBoardSizeX():SetBoardSizeX(value)
		GetBoardSizeY():SetBoardSizeY(value)
		GetUnit.a():SetUnit(value.a)
	EndInterface
	
	Declare create()
EndDeclareModule

Module Test2
	
	Structure Pos
		X.i
		Y.i
	EndStructure
	
	Structure strGerber
		vtable.i
		Identification.q
		BoardSize.Pos;in mm
		DrawScaling.f
		Unit.a;mm/inch
	EndStructure
	
	Procedure create()
		Protected *this.strGerber=AllocateStructure(strGerber)
		*this\vtable=?vtable
		ProcedureReturn *this
	EndProcedure
	
	Procedure.q _GetIdentification(*this.strGerber)
		ProcedureReturn *this\Identification
	EndProcedure
	
	Procedure _SetIdentification(*this.strGerber,value.q)
		*this\Identification=value
	EndProcedure
	
	Procedure _GetBoardSizeX(*this.strGerber)
		ProcedureReturn *this\BoardSize\X
	EndProcedure 
	
	Procedure _SetBoardSizeX(*this.strGerber,value)
		*this\BoardSize\X=value
	EndProcedure
	
	Procedure _GetBoardSizeY(*this.strGerber)
		ProcedureReturn *this\BoardSize\Y
	EndProcedure
	
	Procedure _SetBoardSizeY(*this.strGerber,value)
		*this\BoardSize\Y=value
	EndProcedure
	
	Procedure.a _GetUnit(*this.strGerber)
		ProcedureReturn *this\Unit
	EndProcedure
	
	Procedure _SetUnit(*this.strGerber,value.a)
		*this\Unit=value
	EndProcedure
	
	DataSection
		vtable:
		Data.i @_GetIdentification(),@_SetIdentification()
		Data.i @_GetBoardSizeX(),@_SetBoardSizeX()
		Data.i @_GetBoardSizeY(),@_SetBoardSizeY()
		Data.i @_GetUnit(),@_SetUnit()
	EndDataSection
EndModule

[Rinzwind]

Nope. With a few language additions structures could be a way better alternative for modules. As discussed multiple times before, but ignored by PB owner(s). Fully optional OOP-light idea.

[benubi]

I believe even in most OOP languages you have to go the way with GetVariable() methods to get the private variables of an "external" object. There's no private, public and friend classification of objects in PB which would be the way other languages handle access restrictions. I don't think that a structure in a OOP language will have elements defined as private or public, instead it's the entire structure pointer that would be public or private, but for objects (!) this will be different. In PB there's no object handling like that, the "objects" are structure pointers with a virtual table pointer as their first element.

[NicTheQuick]

You could do it like this maybe:

Code: Select all

Structure Gerber
	Identification.q
	BoardSize.Pos;in mm
	Unit.a;mm/inch
EndStructure

Structure GerberInternal Extends Gerber
	DrawScaling.f
EndStructure

The programmer using your module knows only about the Gerber structure but internally you simply use GerberInternal which has additional attributes.

Securely protecting the access to DrawScaling however will not be possible without creating a dedicated library or DLL/SO with its own memory management.

[Quin]

The only language I've seen that puts access modifiers on struct fields is Rust, and that's partially because they basically treat structs like objects anyways (e.g. you can have methods on your struct). It would be really nice if PB could also adopt this, but I highly doubt it

[NicTheQuick]

The only language I've seen that puts access modifiers on struct fields is Rust, and that's partially because they basically treat structs like objects anyways (e.g. you can have methods on your struct). It would be really nice if PB could also adopt this, but I highly doubt it

There are other languages too: Java, C++. Even Python has that possibility but there it is more like a convention and the IDE would not allow you to access these fields, or you work with the @property decorator.

[jacdelad]

Thanks to all with the answers. Extending the structure will leave the values accessible, though experimenting would be needed. I think I'll need an external object to do this.
XProfan is skso able to mark parts of a structure as private, that's why I asked. Since it can deploy precompiled units (=precompiled module) the private parts are kept truly private.

[Kulrom]

In my opinion there is too much difficulty in hiding fields.
There are no hidden fields in classes in Python. And this doesn’t upset anyone. There is an agreement that hidden fields and methods begin with the character "_". For example "_field" or "_method". And the programmer does not use them. That's all.
If someone wants to shoot themselves in the foot, they will do it anyway.
If there is only one programmer, then this is not a problem at all. If the team is small, then you just need to discuss the rules.

[jacdelad]

As long as PureBasic doesn't have any kind of precompiler which obfuscates the code I'll have to release it in full anyway. O worry more about someone accidently changing somethibg, than more about hiding something.