Simple approach to call private methods in modules

[Justin]

I really miss an option for a module to see the private procs of another module, like it has been requested:
Mod2 FriendOf Mod1
Mod2 has access to Mod1 private procs.
So i came with this simple workaround, mark the shared procs as runtime and use a public Invoke() proc.

Code: Select all

DeclareModule Mod1
	Declare Invoke(name.s, p1=0, p2=0, p3=0, p4=0)
EndDeclareModule

Module Mod1
	Procedure Invoke(name.s, p1=0, p2=0, p3=0, p4=0)
		Define.i proc
		
		proc = GetRuntimeInteger(name)
		If (proc)
			ProcedureReturn CallFunctionFast(proc, p1, p2)
		EndIf
	EndProcedure
	
	Runtime Procedure Private(a.i, b.i)
		ProcedureReturn a + b
	EndProcedure
EndModule

UseModule Mod1

Debug Invoke("Mod1::Private()", 2, 2)

[NoahPhense]

Very kewl.. been programming since elementary school, haven't yet seen or used modules in basic, vb, ib, or pb.. Don't see anything in the help file either on any of those module commands. Enlighten me.

-np

[Danilo]

With global Invoke:

Code: Select all

ProcedureC Invoke(name.s, p1=0, p2=0, p3=0, p4=0, p5=0, p6=0, p7=0, p8=0, p9=0)
    Define.i proc
    
    proc = GetRuntimeInteger(name)
    If (proc)
        ProcedureReturn CallCFunctionFast(proc, p1, p2, p3, p4, p5, p6, p7, p8, p9)
    EndIf
EndProcedure


DeclareModule Mod1 : EndDeclareModule

Module Mod1
    Runtime ProcedureC Private(a.i, b.i)
        ProcedureReturn a + b
    EndProcedure
EndModule


DeclareModule Mod2 : EndDeclareModule

Module Mod2
    Runtime ProcedureC Private(a.i, b.i, c.i, d.i)
        ProcedureReturn a + b + c + d
    EndProcedure
    
    Runtime ProcedureC Private2(a.i, b.i, c.i, d.i, e.i, f.i, g.i)
        ProcedureReturn a + b + c + d + e + f + g
    EndProcedure
EndModule



Procedure main2()
    Debug Invoke("Mod1::Private()",  2, 2)
    
    Debug Invoke("Mod2::Private()",  2, 4, 6, 8)
    
    Debug Invoke("Mod2::Private2()", 2, 4, 6, 8, 9, 10, 11)
EndProcedure

Procedure main()
    main2()
EndProcedure

main()

Debug "OK"

Of course has limitations (Integer arguments only) and little bit overhead (always 9 arguments pushed on stack).
Runtime functions must be ProcedureC for the variable arguments.

[Justin]

They should put this feature now they are in the works, would make modules much more usable.
Mod 2 Extends Mod1

[NoahPhense]

I still don't understand modules. Is there any help files on this?

[BorisTheOld]

I really miss an option for a module to see the private procs of another module, like it has been requested:
Mod2 FriendOf Mod1
Mod2 has access to Mod1 private procs.

It's ideas like this that give programming a bad name.

Procedures are private for a good reason -- to protect them from the outside world. By definition, if a procedure is accessible from outide the module, then it's not private and should be properly declared as public.

[davido]

Hi NoahPhense,

Please take a look at this post by TI-994A:

http://www.purebasic.fr/english/viewtop ... 43#p418143

I didn't know anything about Modules. I found this very helpful.
I hope you do, too.

[Justin]

I really miss an option for a module to see the private procs of another module, like it has been requested:
Mod2 FriendOf Mod1
Mod2 has access to Mod1 private procs.

It's ideas like this that give programming a bad name.

Procedures are private for a good reason -- to protect them from the outside world. By definition, if a procedure is accessible from outide the module, then it's not private and should be properly declared as public.

In C# is called "protected", the procedure is only visible to its class and its inherited(friendof) class(module).

[BorisTheOld]

In C# is called "protected", the procedure is only visible to its class and its inherited(friendof) class(module).

There's a significant opinion in the world that allowing such things is the OOP equivalent of spaghetti code.

One of the major problems with inheritance is that maintenance becomes a nightmare. Over time, classes become dependent on the inner workings of other classes. Changes become more difficult to make, and bugs are more likely to be introduced.

Protected procedures are a menace -- they should be expunged from programming.

[Fred]

One of the major problems with inheritance is that maintenance becomes a nightmare. Over time, classes become dependent on the inner workings of other classes. Changes become more difficult to make, and bugs are more likely to be introduced.

So true. Beautiful on the paper, a nightmare in real life.

[c4s]

[...] Over time, classes become dependent on the inner workings of other classes. [...]

If a programmer knows how to code properly, sticks to general coding standards and complies with the documented behavior (most important!), this would never happen.
That's another reason why we really need a quick and easy documentation system to create documentation for our own code: feature request (eclipse's javadoc-like hover info).

[BorisTheOld]

If a programmer knows how to code properly, sticks to general coding standards and complies with the documented behavior (most important!), this would never happen.

In a perfect world, perhaps. But the reality is that, under the pressure of cost and time constraints, mistakes are made even when standards are upheld.

Inheritance and protected procedures are a Trojan Horse that allows classes to be involved in the inner workings of other classes. Classes are no longer black boxes with public methods. Over time, often with thousands of classes to maintain, conflicts begin to appear in the hierarchy of classes and base classes. And these problems are causing people to question the current concepts of inheritance and protected procedures.

A modified appoach is to create an instance of the base class within a new class, rather than inherit the base class. The new class can make base class methods and properties visible to the outside world by means of its own public methods. This way, the new class and base class are true black boxes that know nothing of the other's inner workings. New features can be added to both without the risk of conflicts to other classes in the hierarchy.

We've been using this technique for a number of years. Nothing is inherited. We still have old applications using new versions of our classes. And although our classes have evolved and become more complex over the years, we've never had problems.

[USCode]

I haven't downloaded the latest beta yet, but if I understand correctly Modules will typically be most useful on projects with a TEAM environment with multiple developers?

[fsw]

[...] Over time, classes become dependent on the inner workings of other classes. [...]

If a programmer knows how to code properly, sticks to general coding standards and complies with the documented behavior (most important!), this would never happen.

Never say never.
Otherwise people reading this will think you are too far removed from reality.

Don't get me wrong, I actually like the oop approach!
Reality is though (at least with the oop languages I know and use) that if the "source code" or "dev team" size gets to a certain point oop implementations do not hold what they promise. (...which is getting the job done better and faster as procedural approaches)

The only oop implementation I can see getting it better is Go (and it's not even pure oop but, maybe this is what makes the golang implementation more usable in the long run...)

[fsw]

I haven't downloaded the latest beta yet, but if I understand correctly Modules will typically be most useful on projects with a TEAM environment with multiple developers?

The idea is to encapsulate parts of the code.
Depending on the chosen module interface the re-usability and robustness of the code should improve over time.
Also the creation of spaghetti-code should be minimized...
But this depends on how much spaghetti resides in a module

And... no you don't need to be a team in order to benefit from it.

Just be open minded.
But not too open minded, otherwise your brain could fall out.