IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PureBasic Discussion :

PureBasic : Interview de Fred


Sujet :

PureBasic

  1. #1
    Responsable Purebasic

    Avatar de comtois
    Inscrit en
    Avril 2003
    Messages
    1 260
    Détails du profil
    Informations forums :
    Inscription : Avril 2003
    Messages : 1 260
    Points : 9 868
    Points
    9 868
    Billets dans le blog
    8
    Par défaut PureBasic : Interview de Fred
    ç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
    Vous souhaitez participer à la rubrique PureBasic (tutoriels, FAQ, sources) ? Contactez-moi par MP.

  2. #2
    Responsable Purebasic

    Avatar de comtois
    Inscrit en
    Avril 2003
    Messages
    1 260
    Détails du profil
    Informations forums :
    Inscription : Avril 2003
    Messages : 1 260
    Points : 9 868
    Points
    9 868
    Billets dans le blog
    8
    Par défaut
    Réaction d'un allemand suite à la lecture de l'article :



    Je crois que ça veut dire qu'il est content
    Vous souhaitez participer à la rubrique PureBasic (tutoriels, FAQ, sources) ? Contactez-moi par MP.

  3. #3
    Responsable Purebasic

    Avatar de comtois
    Inscrit en
    Avril 2003
    Messages
    1 260
    Détails du profil
    Informations forums :
    Inscription : Avril 2003
    Messages : 1 260
    Points : 9 868
    Points
    9 868
    Billets dans le blog
    8
    Par défaut
    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.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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.
    Vous souhaitez participer à la rubrique PureBasic (tutoriels, FAQ, sources) ? Contactez-moi par MP.

Discussions similaires

  1. besoin d'un admin sgbd sympa pour interview
    Par spacer28 dans le forum Décisions SGBD
    Réponses: 6
    Dernier message: 03/05/2005, 15h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo