Page 1 of 1
Friend Modules
Posted: Tue Jun 25, 2013 1:56 pm
by 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
Re: Friend Modules
Posted: Tue Jun 25, 2013 2:56 pm
by eesau
I was just about to request this feature as it would indeed help with a lot of encapsulation, so +1 from me.
Re: Friend Modules
Posted: Tue Jun 25, 2013 3:34 pm
by 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.
Re: Friend Modules
Posted: Tue Jul 23, 2013 11:15 pm
by 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.
Re: Friend Modules
Posted: Sat Aug 03, 2013 8:29 pm
by grabiller
Fred wrote: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.
Re: Friend Modules
Posted: Sat Aug 03, 2013 8:45 pm
by User_Russian
You mean the inheritance models?
Then the it would be logical.
Code: Select all
Module CDerived Extends CObject
EndModule
Re: Friend Modules
Posted: Sat Aug 03, 2013 8:52 pm
by grabiller
User_Russian wrote: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.
Re: Friend Modules
Posted: Sun Aug 04, 2013 9:42 am
by BorisTheOld
grabiller wrote: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
Re: Friend Modules
Posted: Sun Aug 04, 2013 11:15 am
by User_Russian
BorisTheOld wrote: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
BorisTheOld wrote: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.
Re: Friend Modules
Posted: Sun Aug 04, 2013 11:21 am
by Danilo
User_Russian wrote: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.
Re: Friend Modules
Posted: Sun Aug 04, 2013 11:50 am
by grabiller
BorisTheOld wrote:
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).
BorisTheOld wrote:
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.