je ne savais pas trop où coller cette info, alors pourquoi pas ici ?
Voici ce qui se trame en coulisse pour une prochaine version, la gestion des modules. Rien n'est sûr, mais enfin si Fred en parle, c'est qu'il y pense très fort
Si j'ai bien compris, les modules permettront de réutiliser du code plus facilement. Freak suggère d'ailleurs d'utiliser les modules quand ils seront disponibles pour créer nos bibliothèques et les distribuer.
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.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
| ; 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 |
Et quelques commentaires de Freak, co développeur avec Fred.
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.
0 |
0 |
