Classes in PureBasic

[Shield]

I miss a feature to protect a function in module. Protected functions only available inside the module block.

+1

And: I hope structures can be nested inside modules too, right?

[Danilo]

I miss a feature to protect a function in module. Protected functions only available inside the module block.

Code: Select all

Module DirectX

   Private state.l

   Procedure New_OpenScreen(..)
      SetState(1)
      ; ...
   EndProcedure

   Private Procedure SetState(_state)
      state = _state
   EndProcedure

EndModule

Module OpenGL

   Private state.l

   Procedure New_OpenScreen(..)
      SetState(2)
      ; ...
   EndProcedure

   Private Procedure SetState(_state)
      state = _state
   EndProcedure

EndModule


OpenModule DirectX ; change to OpenGL to use another implementation

    scr = New_OpenScreen(...)

    SetState(...) ; error: Private function

    state = 5 ; error: Private variable

CloseModule

[luis]

It's better than nothing!

I'm not sure.

My problem is Fred said, if I understood correctly from those few words, you can write a procedure beep() in a module MOD, call it from inside your module code with beep() and one day if someone define a proc with the same name within a user lib or maybe (it's not clear) simply in some user code which is using your module this will break your module and you will have to go in and replace the beep() with MOD::beep() (actually, MOD_beep() ... sic).

Shouldn't be exactly the other way around ? You write your module and it's protected from outside influences.

You call beep() from other procedures in your module without worrying about what's happening outside.
Then, if when you write your module you know it will need/depend from another module or library you call that beep with OTHERMOD::Beep() or ::Beep() if it's inside a userlib or if it's a PB command. But in this case you know you WANT to call something that's outside.

All this doesn't sound right to me at all.

[ts-soft]

like this:

Code: Select all

Module DirectX

  Private Procedure SetState(_state)
    ...
    ...
    ProcedureReturn result
  EndProcedure
  
  Procedure New_OpenScreen(..)
    bla = SetState(1)
    ; ...
  EndProcedure

EndModule


OpenModule DirectX ; change to OpenGL to use another implementation

  scr = New_OpenScreen(...)
  
  SetState(...) ; error: Private function

CloseModule 

And variables should always protected.

[Shield]

Then, if when you write your module you know it will need/depend from another module or library you call that beep with OTHERMOD::Beep() or ::Beep() if it's inside a userlib or if it's a PB command. But in this case you know you WANT to call something that's outside.

Good point! A module should definitely prefer its own functions over external ones.

[User_Russian]

I miss a feature to protect a function in module. Protected functions only available inside the module block.

http://www.purebasic.fr/english/viewtop ... 15#p403131

[luis]

Tired to never get an answer, so I give up.
Bookmarked my first post about this and we'll see when it will be actually implemented.
Bye guys.

[skywalk]

While I welcome the possibility of modules, I already create explicit procedures with:
mynewlib_function1()
mynewlib_function2()

Calling these procedures without some prefix would be very confusing.

If the procedures are inside a structure, I get isolation for free.
mystruc\function1()

And no new keywords to learn

[c4s]

I miss a feature to protect a function in module. Protected functions only available inside the module block.

http://www.purebasic.fr/english/viewtop ... 15#p403131

I like your suggestion very much. Would be awesome if this private/public thingy would be implemented too!

[Fred]

As you seem interested by the module topic, here is our draft, so you can get a better idea. Please keep in mind than it's no promise, we can drop it if we change our mind so don't expect it for the next version.

Code: Select all

      ; Here is my suggestion:
      ;  - everything inside a module is "protected" by default. no extra "protected" keyword exists
      ;  - "External" makes something visible on the outside
      ;  - visible items can be accessed as <ModuleName>_<ItemName>
      ;  - OpenModule makes them available without prefix
      ;  - Things like EnableExplicit, EnableAsm, DisableDebugger or OpenModule
      ;    should always be on their default state after a "Module", and be reset
      ;    to what they were at OpenModule after a "EndModule"
      ;
      ; So a module is basically totaly separate from compilation outside in terms of naming
      ; and compiler behavior.
      ;
      ;
      ; As for overwriting names of PB functions: I think we should simply disallow it
      ; to avoid any possible confusion. The PB functions have very descriptive names (except math maybe),
      ; so i think it is no problem
      ;
      ; About the "all protected by default":
      ;   If you want a list of globals like the IDE "Common.pb", just put that in a module too,
      ;   then any module that wants to use it just has to do "OpenModule Common" and it is done.
      ;   This way we have a good separation and still easy access.
      ;
      ;   We could have an optional "AllExternal" kind of keyword to define a module where
      ;   everything is externally visible for this purpose:
      ;
      ;   Module Common AllExternal
      ;     Global A ; no need for an extra "External" keyword
      ;   EndModule

      Module Crypto
        Global Initialized

        #InternalConstant = 128
        External #ExternalConstant = 10

        Procedure Cipher()
        EndProcedure

        External Procedure InitCrypto(info)
          Initialized = 0
        EndProcedure

        External Procedure StartCrypto()
          Cipher()
        EndProcedure

      EndModule

      OpenModule Crypto
        InitCrypto(#ExternalConstant)
        StartCrypto()
      CloseModule Crypto

      Crypto_InitCrypto(#Crypto_ExternalConstant) ; this works also outside

      ; Example for separation of the explicit state etc:

      EnableExplicit

      Module Something
        ; here, EnableExplixit is off, until set otherwise

        OpenModule SomethingElse
        DisableDebugger
        ; ...
      EndModule

      ; here, EnableExplicit is on again, the debugger is off and "SomethingElse" is not open

[Shield]

Looks promising.
But I still think it should be allowed to redefine PB functions in modules,
for general reasons and those which luis mentioned. What about WinAPI functions?
Structures inside modules?

I think some kind of global access modifier would be great, so if a module defines
a function called Random() we can still use PB's function by writing something like
global\Random(). Same goes for constants: global\#Black.

[PMV]

I don't think the unterdline-symbol to split the prefix is a good choise ...
Better is to have something that is not allowed in procedure-names
and somewhere else ...
But the rest is solid and thats what i expected Very nice!


But still as you mention again ... who knows how many years we
still have until that? I will be glad in any case when it comes.
Would be a good feature for v6.00, wouldn't it?

[User_Russian]

Fred, whether to support the module in module?

Code: Select all

Module Crypto

  Module My
     
  EndModule
  
EndModule

When can we expect the realization this idea? After how many years?
Forum topic for more than 8 years ....

[fsw]

Surely nobody wants that adding things to PureBasic will become a coding nightmare for Fred & Co to get this working right, but also over-complicates things too much for the user.

Now lean back and look at Go's simplicity:

A main file gets this at the top:

Code: Select all

package main

A main file can include other files; if they have this at the top:

Code: Select all

package main

they are part of the main module.

If you import another module you do:

Code: Select all

package main
import "MyMod"

and a file with this at the top:

Code: Select all

package MyMod

gets imported.

Why should PureBasic become more complicated than Go?
It doesn't!
Just exchange "package" with "module" and you're done

peace

[freak]

A few comments from my side:

About the '_' as separator:
One benefit of this choice is that it makes the entire Module feature just "syntactic sugar": The compiler can internally turn a program with modules into a valid PB program with no modules without changing the qualified (module+local) name of any lexical elements. This makes things simpler because other parts of PB (mainly the debugger) do not need to know about modules at all. Introducing a new separator means that these other parts need to be able to deal with modules as well. This is of course not impossible to do, but the '_' method makes it a lot simpler. As Danilo said: It would be a little like With/EndWith: Something that the compiler can resolve early on and then treat the code like an ordinary PB source.

In this concept, the module feature is just an extension of what people are doing already to separate their codes into local parts. I don't think the '_' is any less good in this respect that another separator. There is no confusion between an X_Foo() procedure that belongs to module X and another X_Foo() procedure that you write elsewhere because you can't. They refer to the same thing. The declaration of the second one will result in a duplicate procedure name error. Wouldn't it be more confusing to have an X::Foo() and X_Foo() procedure in the same code and they refer to different things? So if you already try to avoid such confusions then using '_' as the actual separator does not impose a further limit anyway.

Redefining PB functions:
The goal is to encourage writing code that is easy to read and maintain. How is code easy to maintain if you redefine a well known PB function (to which F1 will bring you the PB help) with some custom definition. Its a recipe for problems. PB functions, WinAPI functions and constants are language features and available everywhere. Redefining them is an error. This way you can be sure that OpenWindow() is actually the documented PB function and not something else.

As for somebody writing a userlib with the same command: You have to manually copy a userlib into you PB folder, so its not like this will happen by accident. Besides, PB does not have an official support for creating userlibs from PB code and the ones written in C are not that numerous. Because modules offer the better features for separating names and are essentially "userlibs in source form", we will encourage people to distribute their libs as modules and not libraries in the future.

Finally, PB already has a mechanism that allows redefining PB commands: Macros. If you really need to replace a PB command you can already do it. You don't need Modules for that.

Modules in modules:
I don't see a common need for this. I have a hard time coming up with a useful example for it to be honest. And the semantics of such a feature would be hard to define and understand. Once again: we are trying to keep things understandable and not make them unnecessarily complex.

> When can we expect the realization this idea? After how many years?
> Forum topic for more than 8 years ....

Its not like we did nothing all these years. Look at the release history. What other feature should we have dropped to get the time for this?