ça se passe ici
On y trouve des informations sur le devenir de PureBasic.
C'est en anglais , si des courageux veulent traduire l'article, merci de partager :)
Version imprimable
ça se passe ici
On y trouve des informations sur le devenir de PureBasic.
C'est en anglais , si des courageux veulent traduire l'article, merci de partager :)
Réaction d'un allemand suite à la lecture de l'article :
http://trollkind.comaoma.de/images/thehemd.jpg
Je crois que ça veut dire qu'il est content :P
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 :ccool:
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.
Citation:
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.
Et quelques commentaires de Freak, co développeur avec Fred.Code:
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
Citation:
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.