Friend Modules

[Shield]

Hello!


I really like the new additions the beta version brings.
Unfortunately, I didn't have enough time to properly test the new module support,
so my request might already be obsolete or being discussed somewhere else.

If so, please blame my slow connection at that bunker *sigh* here that didn't give me a great
change to keep reading frequently what's going on here...


Anyway I'd like to have a way to declare "friend modules":
Module Foo FriendOf Bar

This gives the module Foo the ability to access private members of the Bar module.
Of course it would be even better if we could specify members as public, private and perfected (friend).

This would greatly increase the possibilities of encapsulation as members can be
hidden from the outside but made available among specific modules.


What do you guys think?



Thank you


Shield

[eesau]

I was just about to request this feature as it would indeed help with a lot of encapsulation, so +1 from me.

[Fred]

Altough I can fully understand the request, we would like to keep the module stuff as simple as possible, so class like stuff like protected, override, friend, etc. won't fit in it. If you want to share "private" stuff, you can do a "Common" module with everything public, and then "UseModule Common" in every module which needs it.

[Justin]

A pity if is not included, i don't think it introduces any additional complication and would be an awesome feature.
Using a common module with everething public kind of breaks the purpose of a module wich is encapsulation, it is not very diferent than a simple include.

[grabiller]

Altough I can fully understand the request, we would like to keep the module stuff as simple as possible, so class like stuff like protected, override, friend, etc. won't fit in it. If you want to share "private" stuff, you can do a "Common" module with everything public, and then "UseModule Common" in every module which needs it.

Hi Fred,

Please, think again about it.

Albeit I understand class stuff like 'protected', 'override', 'friend' etc.. won't fit in, I do think a simple 'Shares' (or any word outside of 'class like stuff' on purpose) would be far sufficient, and would be fully in the spirit of PureBasic features.

Code: Select all

Module CDerived Shares CObject
EndModule

This would allow very elegant and clean encapsulation, and this is just enough for us to deal with our 'Classes'.

Please give a second chance to this idea

Cheers,
Guy.

[User_Russian]

You mean the inheritance models?
Then the it would be logical.

Code: Select all

Module CDerived Extends CObject
EndModule

[grabiller]

You mean the inheritance models?
Then the it would be logical.

Code: Select all

Module CDerived Extends CObject
EndModule

Well,

I would say this would be misleading.

'Extending' an Interface or a Structure makes sense and is intuitive, but 'Extending' a Module seems counter-intuitive to me as the goal is not to extends something but to have access to something, for instance to have access to a private structure while ignoring the rest that can be defined in the Module.

In that way it's closer to the concept of 'Friends', but the actual meaning is 'Share'.

At least, from my POV that is

Cheers,
Guy.

[BorisTheOld]

but the actual meaning is 'Share'.

I think this feature will be of limited use, as it will just create the same sort of problems that have been discussed at length elsewhere, such as name conflicts between the derived and shared modules.

Also, your syntax is restrictive, in that multiple modules might need to be shared:

Code: Select all

Module CDerived Shares CObject1, CObject2, ........
EndModule

The current UseModule feature does the same thing:

Code: Select all

Module CDerived
  UseModule CObject1
  UseModule CObject2
  UseModule ........

EndModule

Having worked on many large-scale modular projects, I have to say that I can't see the benefits of your Share feature, or even PB's UseModule feature. Both are too much like Inheritance and they "break" the black-box concept of modules. Think of the problems that would be created if multiple dynamic libraries (dll/so) shared code in each other's address space.

In my experience, the only items that need to be "shared" are constants, macros, and structures. And for those, UseModule isn't needed -- just use Include statements in each module. For everything else, use the "ModuleName::ItemName" notation to access code in other modules.

Code: Select all

Module ModuleName
  IncludeFile "Constants.pbi"
  IncludeFile "Macros.pbi"
  IncludeFile "Structures.pbi"

EndModule

[User_Russian]

The current UseModule feature does the same thing:

You are wrong.

Code: Select all

DeclareModule x
EndDeclareModule

Module x
#Const = 2
Procedure Test()
EndProcedure
EndModule


DeclareModule y
EndDeclareModule

Module y
UseModule x
x=#Const
Test()
EndModule

Module ModuleName
IncludeFile "Constants.pbi"
IncludeFile "Macros.pbi"
IncludeFile "Structures.pbi"

EndModule

It does not support IDE.
And besides, unreasonably increase the size of the program.

[Danilo]

And besides, unreasonably increase the size of the program.

Constants, Macros, and Structures are only declarations for the compiler and not included into the executable.

[grabiller]

Also, your syntax is restrictive, in that multiple modules might need to be shared:

Code: Select all

Module CDerived Shares CObject1, CObject2, ........
EndModule

Structures and Interfaces only allow single inheritance, multiple inheritance is considered as bad practice. So this syntax should not be allowed (following Purebasic spirit).

The current UseModule feature does the same thing:

Code: Select all

Module CDerived
  UseModule CObject1
  UseModule CObject2
  UseModule ........
EndModule

No, this does not work inside 'Module'. UseModule does not give you access to private data declared in another Module.

Yet the goal is not to mix names inside the same namespace. So I agree that UseModule should not even exist.

Perhaps another alternative would be to use something like 'AccessModule':

Code: Select all

Module CDerived
  AccessModule CBase
  ; then we would do:
  Structure Instance_t Extends CBase::Instance_t
    ; ../..
  EndStructure
EndModule

Note it would still be required to use the other Module prefix (CBase::Instance_t).

Perhaps it would be clearer this way, away from inheritance concepts.

It would be just an intuitive way to access private data from another module without mixing namespaces.

Cheers,
Guy.