Antoine BEUGNARD

Poste

Enseignant Chercheur

Localisation

Brest

Contact information:

Tél.

+33 2 29 00 14 23

Courrier

Technopole Brest Iroise
CS 83818
29238 Brest cedex 3
    Biographie

    Biographie

    Je suis un ancien élève de l'ENST-Bretagne (1986). J'ai reçu mon titre de Docteur 3ème Cycle en Informatique à l'université de Rennes 1 en 1993. J'ai passé mon habilitation à diriger des recherches en 2005 et suis professeur à Telecom Bretagne, maintenant IMT Atlantique, depuis décembre 2007.

    J'ai travaillé auparavant chez Michael Jackson France, où j'ai participé à la création d'un environnement de développement pour la méthode JSD (Jackson System Development) en Smalltalk.

    Après m'être intéressé à la sémantique de liaison dynamique des langages objets, à la spécification par contrat et à la notion d'abstraction de communication, mes centres de recherche actuels sont la modélisation (son sens, ses notations, ses propriétés comme la composition, etc) et la vérification statique de noms en contexte de langages hétérogènes.

    Depuis 2017, j'applique mes recherche au domaine de l'Industrie du Futur et plus spécifiquement au jumeau numérique. Je participe au groupe de travail "Jumeau Numérique" de l'Alliance Industrie du Futur.

    Activités de recherche

    Membre du Lab-STICC (UMR 6285) et de l'équipe P4S.

    Mes principales activités de recherche sont liées à la conception de logiciel et en particulier à l'étude des frontières entre entités logicielles (composant, connecteurs, classes, etc.).

    Antoine Beugnard, Contribution à l'assemblage d'entités logicielles, habilitation à diriger des recherches, Université de Bretagne Sud, 5 décembre 2005.

    Je me suis intéressé à l'ingénierie des modèles et en particulier à l'explicitation du processus de conception et à la fédération de modèles. Je participe au développement d'Openflexo.

    Enfin, j'applique mes recherches au jumeau numérique.

    Les jumeaux numériques

    Système cyberphysique couplé à un autre système cyber-physique de référence, le jumeau numérique est un outil polymorphe. Il est un modèle du système de référence qu'il supervise. Mais il offre également des outils d'analyse, de prédiction, de simulation qui permettent d'améliorer le système de référence. 

    Les "cloud components"

    Une généralisation des abstractions de communication. La notion de cloud component propose un changement de paradigme dans l'assemblage des composants logiciel : faire disparaître les connecteurs au profit de l'explicitaion des propriétés de localisation.

    Publications dans le cadre de la thèse de Ali Hassan

    Les abstractions de communication

    La communication dans les applications distribuée vue comme un composant.

    Publications dans le cadre des thèses de Eric Cariou, Selma Matougui, Chantal Evelyne Kaboré et An Phung Khac

    Redéfinition, Surcharge, liaison dynamique

    La comparaison de la sémantique de la liaison dynamique dans de nombreux langages objets...12 langages testés, 10 comportements différents ! 
    Des exemples pour mieux comprendre la différence entre redéfinition, surcharge, covariance, contra-variance, liaison dynamique simple ou multiple.

    Publications avec Salah Sadou (Université de Bretagne Sud)

    En cours

    Sylvain Guerrin

    Fédération de modèles : FML, un langage d’assemblage de modèles pour l’interopérabilité
    sémantique de sources d’information hétérogènes

    Terminées

     

    Paul Perrotin

    Analyse de la vulnérabilité humaine dans les systèmes sociaux-techniques. Salah Sadou (Archware, IRISA Vannes) co-directeur.

     

    Ngoc Tho Huynh

    Un processus de développement pour développer des logiciels adaptatifs à partir d'arbre de variabilités, co-encadrée par MT. Segarra.

    Ali Hassan

    L'utilisation de la localisation pour la spécification des composants logiciel

    Quyet Thang Pham

    Typage des modèles pour la réutilisation des transformations de modèles

    An Phung Khac

    Thèse sur des composants répartis auto-adaptable, co-encadrée avec JM. Gilliot et MT. Segarra.

    Chantal Kaboré

    Thèse sur un processus de conception de composant réparti par transformation de modèles.

    Selma Matougui

    Proposition d'un processus de réification d'abstraction de communication comme un connecteur associé à des générateurs, PhD thesis, Université de Rennes 1, école doctorale Matisse, December 2005

    Eric Cariou

    (ps.gz)Contribution à un Processus de Réification d'Abstractions de Communication, PhD thesis, Université de Rennes 1, école doctorale Matisse, June 2003

    Olivier Aubert

    (abstract, pdf) Patron de conception pour l'analyse et la construction de systèmes à comportements autoadaptatifs, PhD thesis, Université de Rennes 1, école doctorale Matisse, December 2001

    Cours-Enseignements

    J'enseigne le génie logiciel en formation d'ingénieur, en formation par alternance et en formation continue.

    Le message général est :

    • explicitez ! le processus et le produit dans chacune dans leur forme ; de la plus abstraite - besoin, spécification - à la plus concrète - la mise en oeuvre - en passant par l'architecture.
    • adaptez ! les règles, les outils, les méthodes en s'ajustant au contexte,...
    • justifiez ! vos décisions, vos adaptations...

    J'enseigne aussi la conception avec UML, un langage objet (Java) et des  éléments de base comme la concurrence, la distribution ou les patrons (présenté comme un outil de transfert de savoir-faire fondamental.)

    Je suis un adepte de peu de cours, mais des mises en situation avec des simulations de projets - une forme de pédagogie active - pour aborder à la fois les aspects organisationnels et technique du développement logiciel.

    Je suis responsable de la Thématique d'Approfondissement (TAF) : Ingénierie Logiciel des Systèmes Distribués (ILSD)

    Sinon, je participe ponctuellement à de nombreux enseignements... en soutien.

        -----BEGIN PGP PUBLIC KEY BLOCK-----
        Comment: GPGTools - http://gpgtools.org
        
        mQENBFHafPgBCAC8ao6eTjFzSL6MEU0RaNBGpNMm1WBLJm0m2cvr3gPjs10OZoov
        WtgDYEEj1V43WMrwXwhJGsnyAdzhpesOc4cQl3Kc4GrKM3L7BzbrfkE83izGYDZl
        16igB36AWu3ER/ZqN++79Mj3DOTY3J74sDMT9eiEyvlFsxYk0U5kjALJWazYlFVu
        yqyKNtZjw4YIREA2PXgBRYubko5VSQnPTCHVnUOAFJgQLP3c95aPYZBe0CMClzkr
        DtFlR+rKLuel8UpI1EChZbjK0H+zfmrCcnsqjRMgF+2d7QhoLRkKnV/pib4/qusJ
        meI45i/+QR/0eWJbw1m9XM7jRUwwOdzHz1iLABEBAAG0PEJldWduYXJkIEFudG9p
        bmUgKFBlcnNvbmVsbGUpIDxhbnRvaW5lLmJldWduYXJkQGxhcG9zdGUubmV0PokB
        PQQTAQoAJwUCUnGczwIbLwUJB4YfgAULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAK
        CRBWMXyjGoxhWuyrCACRHOWbM9SB+O8vURVqBYb968yNb8PZVucIMKkaXmdKL0sZ
        yTbHMQ0Gq4akfFWLYFMtMvybrdZ0cgAA7oQMIH3XuTXBHzy2FBwhZrH6+Xxm8pO+
        b+a+nzdeQCfmg9cX25sd97+UYVCgublqA3UU06vDXpTaFR3FMiym/+4LdX2Srz9F
        7Y+FFRG2VN3UrVR2PW4bv7pkKFUv3qk4yekdnnPv73Kuvmhb/VcQFtdRowu9wyxp
        0BprChqhhn2HP4ktZJ+MUgi+pfBn1kcubTI4aJ74ct1FkGJlUWc2s1p8DqbyJM8V
        VOrfUhvuh9IEKlHFCyDirJoNxbifISktrlfdP2LqtDdBbnRvaW5lIEJldWduYXJk
        IDxhbnRvaW5lLmJldWduYXJkQHRlbGVjb20tYnJldGFnbmUuZXU+iQFABBMBCgAq
        AhsvBQkHhh+ABQsJCAcDBRUKCQgLBRYCAwEAAh4BAheABQJScZ0/AhkBAAoJEFYx
        fKMajGFapEYH/i12F0EZiBU2phFrWMG6MxChYyFNzgZ0S3XY8uBGxWhbsr+R2xlC
        Y3ooCfueRp1bw9+ZFq084oRT+GBqlifBsv/kGwutmchaLP4ocg0xkEwwEYPougD3
        J3s7Ouxn96Dt5k4JAZcStbfCTbDYjw9UjCN2RUD/jbBPqjGer+0225SUJYSrKjk3
        aAGrNfk5TixpqXED+NlISMuFJGLUhfcLYRnm9ElDenRNi1TLCkdX02oL4Xq6bdvu
        Pzj9SIyPi+ZPu/AsD5Gfk2VBLBWwa9nS6NTQIpal7xje3tXqukTNjRWCZKSsrb/N
        lH39hesIWKOXOonekMZ1p4ocJvACOgCXlMm5AQ0EUdp8+AEIAOFh+wgnaMDDChxD
        dUgU02vH2PSmebNl7MxP9aarTAyLHPBEsMDSVVOvnmDqLW2jWePsicmn5FHxDYTp
        3wz2ZdOmwTGFPP67QguDQyy8rVDt5ZC5wCYGCBbuQlAhlMlj7lWNWNTsvSOl2J2p
        urDNCX615XRejaBc9OOCq6GRr3cn49mD9C1x/WckE71EjOD9xbprNMu5GSgyDFfA
        aw+GspCSwBPwjXPugYTsAoqVSU8ZlMwR+zXlchUQrR6yuFRZ+ikaX/58iPqjMbUC
        1l4CgjB7b7QDfG07p26u9GQO6sME322E3BwIGPEQ5LSxYh0A2UQuwIEC6qEj1th/
        zqJcUvUAEQEAAYkCRAQYAQoADwUCUdp8+AIbLgUJB4YfgAEpCRBWMXyjGoxhWsBd
        IAQZAQoABgUCUdp8+AAKCRD28iqsxxnZXx1XB/9kmBAk9X4Nlc9JKW4+kaLd2Bdz
        A0Zbq37RVrI1lhYx+yuPt0GwJZOK0r4xmp0BysrUOchoBW5DGQ0aOiw+wbu6Avcx
        B60zHeaJLjKPOU/AHetEaX1nIcLu/eBYSmSqdNMWAmNtXZ3+yiHgo8iLZrNcSzi5
        7iwNvh7ff/jeTd1L4MZDKsIW/fk4i66J9OI/HljlEGmMX3m+UDIzoywb2j5q4dls
        41XhSBQ6Zys4izAlzk74qXQ3C0g4kaI7HDfKwVR+Es+4z1zFZkz7cJfrdcpm+Jq9
        vsz4vCzVeV7FHsSK8CGTy99aSfvDcQ0M0/Ljdc1MSDhxyY1QLWNkBm9H9XG7r2gI
        AI4W7rv3Z9vqa70AX2LLdjIa+8odbKL9KWQYKETNOMhGNrXq0aCCtzTAzAYW5vW9
        UlQ5AfG4WTUxrvU3cgk0qF0BIJ6DHLlDZnSyZqyEe5RAZ2R8MXAf+bvq1JGUR/bN
        XlaWYMa6MXKHaBN0SqdKKfrdsUvjbWKIk1/zyyEG33kX7RFEJ+o4YK0M2ViNzVAV
        Uhk9BcUSTgnrz4rwEQZnAOrruuPetcvdz7blKVo30aiPfnA6FBfSRB5ofyPDKWFs
        iN0+ljgbvzZZRt0r4OmSngoTGD3rfLPWkW3ZMtFD7NTcFyDsUZMygg6ppRVQjlOZ
        UkFiI0pxJydIdEv+c+WS8BI=
        =k77u
        -----END PGP PUBLIC KEY BLOCK-----

        Comparison of various OO languages relatively to their late-binding semantics

        by Antoine Beugnard

        Abstract.
        We observe the various interpretations of overriding and overloading in object oriented languages. With the description of an intend, represented as the following UML diagram, we have "naively" implemented in 20 different languages the same piece of code... and obtained 15 different results.

        UML diagram of the experiment

         

        The question is: How will this model behave?

        new (2020) A new language signature with Julia (multiple dispatch)

        new (2019) A new language signature with Go

        (hot) Tables for .NET language interoperability ! Tables A, B and C.
        Not so simple !

        hot Java changed its semantics from 1.3 to 1.4!!! Signature slot (6,2) changed adopting the Visual Basic signature!

        You'll find source of experiment for each language. You are invited to re-do experiments with you own context and compilers. In our experience (for Java and Scala), the semantics of language may evolve... and we are interested in taking track of that. Thanks for you help.

        Outline

        1. The test procedure for a single language...

        2. The test procedures for languages interaction...

        Results are presented in a table 3x6 for all possible calls. Note that only single late-binding is evaluated, and not multiple late-binding, even if some languages enable it (CLOS, Dylan). Results reading help is here. 3. Four proposals for a unified late-binding semantics : A pragmatic, a reasonable (and a non-incremental variant), a strict one and the dont-surprise-the-programner semantics. 4. Tested languages : Ada95, C++, C#, CLOS, Dylan, Eiffel, Go, Java (1.3 and 1.4 are different), Julianice, OCaml, Perfect, Python, Scala (1.1 and 2.0 are different), Ruby, Smalltalk, Strongtalk, Visual Basic (To be tested...Beta, and others. You're welcome if you want to contribute).

        Tested language interaction using 2 .NET languages: VisualBasic/C++, VisualBasic/C#, C++/VisualBasic, C++/C#, C#/VisualBasic, C#/C++

        5. Comparisons for receivers Up u = new Up, Down d = new Down, Up ud = new Down

        6. Tested language interaction using 3 .NET languages: C# client, VisualBasic client, C++ client.
         -- Tested language interaction using CORBA (to be done)

        7. Code transformation in order to simulate the reasonable semantics in Eiffel, Java and C++

        8. Conclusion and future work (PhD, thèses) and discussion...


        1. The programme for testing a single language late-binding semantics

        5 classes are needed. 3 for parameters types (all code in a pseudo language):

        class Top end class
        class Middle extends Top end class
        class Bottom extends Middle end class

        2 for the method redefinition tests. cv for covariant redefinition, inv for invariant redifinition and ctv for contravariant one:

        class Up
        method cv(Top t) print "Up" end method
        method inv(Middle) print "Up" end method
        method ctv(Bottom b) print "Up" end method
        end class

        class Down extends Up
        method cv(Middle m) print "Down" end method
        method inv(Middle) print "Down" end method
        method ctv(Midle m) print "Down" end method
        end class

        A main program instantiates objets and makes all possible calls:
        procedure main()
        Up u = new Up
        Down d = new Down
        Up ud = new Down
         

        -- first column -- second column -- third column 
        u.cv(new Top) d.cv(new Top) ud.cv(new Top)
        u.cv(new Middle) d.cv(new Middle) ud.cv(new Middle)
        u.cv(new Bottom) d.cv(new Bottom) ud.cv(new Bottom)
        u.inv(new Top) d.inv(new Top) ud.inv(new Top)
        u.inv(new Middle) d.inv(new Middle) ud.inv(new Middle)
        u.inv(new Bottom) d.inv(new Bottom) ud.inv(new Bottom)
        u.ctv(new Top) d.ctv(new Top) ud.ctv(new Top)
        u.ctv(new Middle) d.ctv(new Middle) ud.ctv(new Middle)
        u.ctv(new Bottom) d.ctv(new Bottom) ud.ctv(new Bottom)

         

        end procedure

        So what is behavior of this code ?

        For sake of brevity we have suppressed the simple invariant case - inv(Middle) defined in Up and Down - since all languages behave identically. However, some tables include inv lines for compaison purpose. Results are presented in a table 3x6 for all possible calls. Note that only single late-binding is evaluated, and not multiple late-binding, even if some languages enable it (CLOS, Dylan). Results reading help is here.


        2. The programme for testing languages interaction late-binding semantics

        5 classes are needed. 3 for parameters types (all code in a FIRST pseudo language):

        class Top end class
        class Middle extends Top end class
        class Bottom extends Middle end class

        1 for the methods definition (in the FIRST pseudo language):

        class Up
        method cv(Top t) print "Up" end method
        method inv(Middle) print "Up" end method
        method ctv(Bottom b) print "Up" end method
        end class

        1 for the method redefinition tests. cv for covariant and ctv for contravariant redifinition (in the SECOND pseudo language):

        import Up, Top, Middle, Bottom

        class Down extends Up
        method cv(Middle m) print "Down" end method
        method inv(Middle) print "Down" end method
        method ctv(Midle m) print "Down" end method
        end class

        A main program (in a THIRD pseudo language) instantiates objets and makes all possible calls (in the FIRST pseudo language or SECOND pseudo language):
        procedure main()
        Up u = new Up
        Down d = new Down
        Up ud = new Down
         

        -- first column -- second column -- third column 
        u.cv(new Top) d.cv(new Top) ud.cv(new Top)
        u.cv(new Middle) d.cv(new Middle) ud.cv(new Middle)
        u.cv(new Bottom) d.cv(new Bottom) ud.cv(new Bottom)
        u.ctv(new Top) d.ctv(new Top) ud.ctv(new Top)
        u.ctv(new Middle) d.ctv(new Middle) ud.ctv(new Middle)
        u.ctv(new Bottom) d.ctv(new Bottom) ud.ctv(new Bottom)

         

        end procedure


        3. Possible Unified Semantics

        We have included inv(Middle) calls in order to show the discontinuity that appears in the thrird column when an invariant semantics is chosen (C++, C#, Java,...)
        Here are rationale of these semantics...(comming soon)
         

        Table 1 : Reasonable semantics

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Down Down
        inv(Top) Compilation error Compilation error Compilation error
        inv(Middle) Up Down Down
        inv(Bottom) Up Down Down

        Note : Almost never implemented ! The most specialized method selected, covariant and contravariant redefinition possible. Slot (5,3) for incremental compilation. The third columns is continuous...
         

        Table 1 bis : Non incremental Reasonable semantics

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Down
        ctv(Bottom) Up Down Down
        inv(Top) Compilation error Compilation error Compilation error
        inv(Middle) Up Down Down
        inv(Bottom) Up Down Down

        Note : Almost implemented by CLOS and Dylan. The most specialized method selected, covariant and contravariant redefinition possible. Slot (5,3) prevents incremental compilation. The third columns is still continuous...
         

        Table 2 : Pragmatic semantics

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Down Up
        inv(Top) Compilation error Compilation error Compilation error
        inv(Middle) Up Down Down
        inv(Bottom) Up Down Down

        Note : Invariant semantics. Covariant and contravariant forbiden. This is C# choice is close to Java and C++ one. The third column HAS A DISCONTINUITY
         

        Table 2bis : Strict semantics

         
         
        u
        d
        ud
        cv(Top) Up Down Down
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Compilation error Compilation error
        ctv(Bottom) Up Down Down
        inv(Top) Compilation error Compilation error Compilation error
        inv(Middle) Up Down Down
        inv(Bottom) Up Down Down

        Note : Redefinitions with different type of argument is forbiden. Down::cv(Middle) and ctv(Middle) cannot be defined but Down::cv(Top) and Down::ctv(Bottom) can.
        Slots (1,2) and (1,3) are yellow since cv cannot be specialized in cv(Middle) but do not generate runtime errors since cv(Top) exists in Down. Covariant redefinitions are forbiden as contravariant ones, the latter generate compilation errors: blue slot(5,3).

        Table 2ter : Dont-surprise-the-programner semantics

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Compilation error Compilation error
        ctv(Bottom) Up Up Up
        inv(Top) Compilation error Compilation error Compilation error
        inv(Middle) Up Down Down
        inv(Bottom) Up Down Down

        Note : Suggested bu Howard Lovatt. Columns 2, d, and 3, ud, should be the same since the object in question is a d. Row 5, ctv(m), column 3, ud, should be E, since most programmers wouldn't expect to have to re-compile super classes when deriving. Contravariance is forbiden.


        My favorites are :
            winner : Table 1; allows consitent covariant and contravariant redefinitions and incremental compilers. Homogeneous behavior.
            outsider : Table 2bis : Simple. Homegenous behavior but misses advantages of Table 1.
            outsider : Table 2 : Close to popular OO languages. Simple incremental modification to compilers of Java and C++ to apply it. But heterogeneous...


        Color interpretation

        • red : runtime error
        • orange : potential runtime error
        • yellow : correct but different from the reasonable semantics (not the most specialized)
        • blue : over-constrained (no solution found while one exists)

        4. Languages semantics

        Table 3 : Ada 95

         

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Compilation error Down Compilation error
        cv(Bottom) Compilation error Compilation error Compilation error
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Up Up

        Note : A lot of over-constraints that may be explain by the phrase (Ada95 Ref. Manual) "No complicated method lookup is involved" 3.9(1e) but the constraints seem be the result of a non-use of argument type conformance. See code and result.


        Table 4 : C++, Scala 1.1

         
         
        u
        d
        ud
        cv(Top) Up Compilation error Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Down Up

         

        Note : Invariant semantics (ud shows that no covariant or contravariant is taken into account); slot (1,2) is over-constrained. See code and results for C++. See code and results for Scala.
         


        Table 5 : C#

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Down Up

         

        Note : Invariant semantics (ud shows that no covariant or contravariant is taken into account). This is the pragmatic semantics. See code and results.


         

        Table 6 : CLOS and Dylan
         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Runtime error Runtime error Runtime error
        ctv(Middle) Runtime error Down Down
        ctv(Bottom) Up Down Down

         

        Note : Close to reasonable semantics, accepts typing runtime risks. For CLOS, see code and results. For Dylan, see code and results.


        Table 7 : Eiffel

         

         
         
        u
        d
        ud
        cv(Top) Up Compilation error Down
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Compilation error Compilation error
        ctv(Bottom) Up Up Up

        Note : Covariant semantics, contravariance forbiden (lines 4, 5 and 6); slot (1,3) is runtime error prone. See code and results.
        A recent proposal from B. meyer to remove the slot (1,3) problem is discussed here : CATcalls.
        A possible code transformation to make Eiffel match the "reasonable sematics".
         


        Table 7.5 : Go

         
         
        u
        d
        ud
        cv(Top) Up Down Down
        cv(Middle) Compilation error Compilation error Compilation error
        cv(Bottom) Compilation error Compilation error Compilation error
        ctv(Top) Up Down Down
        ctv(Middle) Up Down Down
        ctv(Bottom) Up Down Down

        Note: Unusual semantics for object programmers.


        Table 8 : Java before 1.3 and Scala 2.0 (and probably before)

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Compilation error Up

         

        Note: Invariant semantics (ud shows that no covariant or contravariant is taken into account); slot (6,2) is over-constrained. See code and results (java 1.3). See code and results (scala 2.0).

        Table 8 bis : Java after 1.4

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Up Up

        Note : Invariant semantics (ud shows that no covariant or contravariant is taken into account); slot (6,2) could be more specialized (as Visual Basic). See code and results.


        Table 8.5 : Julia

         
         
        u
        d
        ud
        cv(Top) Up Error Error
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Error Error Error
        ctv(Middle) Error Down Down
        ctv(Bottom) Up Error Error

        Note: columns u and ud are the same ; there is no static type in Julia. The ctv(Bottom) leads to a compilation error since multiple dispatch detect an ambiguity that has to be removed. See code and result.


        Table 9 : nice (naive translation)

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Compilation error Up

         

        Note : This is the result of a naive translation. a ctv(Middle) is specified in Down. Multiple late-binding, but contravariance not allowed. See code and results.
        Another translation, more in the spirit of nice, but less naive gives results of table 9bis. See code and result.
         

        Table 9bis : nice

         

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Compilation error Compilation error
        ctv(Bottom) Up Down Down

         

        Table 10 : OCaml

         
         
        u
        d
        ud
        cv(Top) Up Down Down
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Up Down Down
        ctv(Middle) Up Down Down
        ctv(Bottom) Up Down Down

         

        Note : In spite of appearances, no runtime errors could occur since OCaml compiler detects type problems when they exist ! See code and results. I know that Top, Middle and Bottom classes are equivalent in OCaml sense. Hence, this test may appear unfair. In a sense its true. But why couldn't a programmer or a designer decide to have many classes with exactly the same interface but with different method implentation? There is some "semantics" in the name!
         


        Table 10.5 : Perfect

         
         
        u
        d
        ud
        cv(Top) Up Error Error
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Error Error Error
        ctv(Middle) Error Down Down
        ctv(Bottom) Up Down Down

         

        I did not make the test myself.The table is extracted from page 10 of the technical repport NUIM-CS-TR-2005-07, Software Specification, Implementation and Execution with Perfect by Gareth Carter and Rosemary Monahan. As far as I know, it is the first time, the "language signature" is used during the design of a language! Not as a decision tool to choose the semantics, but as a kind of test.


         

        Table 11 : Smalltalk, Python or Ruby

         
         
        u
        d
        ud
        cv(Top) Up Down Down
        cv(Middle) Up Down Down
        cv(Bottom) Up Down Down
        ctv(Top) Up Down Down
        ctv(Middle) Up Down Down
        ctv(Bottom) Up Down Down

         

        Note : Smalltalk is not typed, so many runtime errors could occur ! But there is a very good regularity. See Smalltalk code and results.See Python code and results.  See Ruby code and results.
         


        Table 12 : Strongtalk

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Up Up
        cv(Bottom) Up Up Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Down Down

        Note : Strongtalk is typed and adopts a contravariant redefinition rule. See code and results.


        Table 13 : Visual Basic

         
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Up Up

        Note : Column 2 is strange...as if no contravriant were accepted (as for Eiffel) but for slot (5,2) ! See code and results.

         


        Language interoperability using .NET (2 languages case)

        Table 14 : C# to (managed) C#, Visual Basic, C++
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Down Up

        Note : Code see C# Client here and Component C#, VisualBasic, C++ . All results
         

        Table 15 : C++ to (managed) C#, Visual Basic, C++
         
        u
        d
        ud
        cv(Top) Up Compilation error Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Down Up

        Note : Code see C++ Client here and Component C#, VisualBasic, C++ . All results
         

        Table 16 : Visual Basic to (managed) C#, Visual Basic, C++
         
        u
        d
        ud
        cv(Top) Up Up Up
        cv(Middle) Up Down Up
        cv(Bottom) Up Down Up
        ctv(Top) Compilation error Compilation error Compilation error
        ctv(Middle) Compilation error Down Compilation error
        ctv(Bottom) Up Up Up

        Note : Code see VisualBasic Client here and Component C#, VisualBasic, C++ . All results

        The semantics depends on the calling program language.


        5. Comparisons for each receivers

        Table 17 : Up u = new Up
          Ada95 C++ C# CLOS/Dylan Eiffel Java OCaml Python/Smalltalk VisualBasic
        cv(Top) Up Up Up Up Up Up Up Up Up
        cv(Middle) Compilation error Up Up Up Up Up Up Up Up
        cv(Bottom) Compilation error Up Up Up Up Up Up Up Up
        ctv(Top) Compilation error Compilation error Compilation error Runtime error Compilation error Compilation error Up Up Compilation error
        ctv(Middle) Compilation error Compilation error Compilation error Runtime error Compilation error Compilation error Up Up Compilation error
        ctv(Bottom) Up Up Up Up Up Up Up Up Up

        Note : functional languages (CLOS, Dylan, OCaml, Smalltalk) accept more risks...The distinction between OCaml and Smalltalk is due to the OCaml compiler that would not have compiled code where the type would have trigger errors (yellow is safe !).
         

        Table 18 : Down d = new Down
          Ada95 C++ C# CLOS/Dylan Eiffel Java OCaml Python/Smalltalk VisualBasic
        cv(Top) Up Compilation error Up Up Compilation error Up Down Down Up
        cv(Middle) Down Down Down Down Down Down Down Down Down
        cv(Bottom) Compilation error Down Down Down Down Down Down Down Down
        ctv(Top) Compilation error Compilation error Compilation error Runtime error Compilation error Compilation error Down Down Compilation error
        ctv(Middle) Down Down Down Down Compilation error Down Down Down Down
        ctv(Bottom) Up Down Down Down Up Compilation error Down Down Up

        Note : Line 1 shows 2 over constraints for C++ and Eiffel. Eiffel refuses contravariance. OCaml and Smalltalk are very regular.
         

        Table 19 : Up ud = new Down
          Ada95 C++ C# CLOS/Dylan Eiffel Java OCaml Python/Smalltalk VisualBasic
        cv(Top) Up Up Up Up Down Up Down Down Up
        cv(Middle) Compilation error Up Up Down Down Up Down Down Up
        cv(Bottom) Compilation error Up Up Down Down Up Down Down Up
        ctv(Top) Compilation error Compilation error Compilation error Runtime error Compilation error Compilation error Down Down Compilation error
        ctv(Middle) Compilation error Compilation error Compilation error Down Compilation error Compilation error Down Down Compilation error
        ctv(Bottom) Up Up Up Down Up Up Down Down Up

        Note : Eiffel is not type error free. Functional languages accept Down on line 5 (potential incremental compilation problems).

         


        6. Language interoperability using .NET (3 languages case)

        1. A first library is compiled from the FIRST language (among CS - C# -, VB - VisualBasic -, and VC - managed C++). It contains Up, Top, Middle and Bottom. (3 dll versions)
        2. A second library is compiled from the SECOND language, using the FIRST languages version. It contains the Down class. (3 * 3 = 9 dll versions)
        3. An executable is built from the THIRD language, using one among the 9 previous librairies. (27 exe versions) [source (100 k)]

        C# Client

        The 9 first tables for the C# exe. On each line of 3 tables only the second librairy (Down) changes.
        Results are regular but for slot (1,2) when Down is programmed in C++. So, for instance, replacing a VB/dll by a C++/dll will require a exe C# recompilation !
        Table A is a simplified presentation of these results (where language signature is used as results).

        Tables 20 : CS as Client and Up, Top, Middle, Bottom
        CSCSCS u d ud CSVBCS u d ud CSVCCS u d ud
        cv(T) U/CS U/CS U/CS cv(T) U/CS U/CS U/CS cv(T) U/CS X U/CS
        cv(M) U/CS D/CS U/CS cv(M) U/CS D/VB U/CS cv(M) U/CS D/VC U/CS
        cv(B) U/CS D/CS U/CS cv(B) U/CS D/VB U/CS cv(B) U/CS D/VC U/CS
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/CS D/CS U/CS ctv(B) U/CS D/VB U/CS ctv(B) U/CS D/VC U/CS
        Tables 21 : CS as Client and VisualBasic for Up, Top, Middle Bottom
        CSCSVB u d ud CSVBVB u d ud CSVCVB u d ud
        cv(T) U/VB U/VB U/VB cv(T) U/VB U/VB U/VB cv(T) U/VB X U/VB
        cv(M) U/VB D/CS U/VB cv(M) U/VB D/VB U/VB cv(M) U/VB D/VC U/VB
        cv(B) U/VB D/CS U/VB cv(B) U/VB D/VB U/VB cv(B) U/VB D/VC U/VB
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/VB D/CS U/VB ctv(B) U/VB D/VB U/VB ctv(B) U/VB D/VC U/VB
        Tables 22 : CS as Client and C++ for Up, Top, Middle Bottom
        CSCSVC u d ud CSVBVC u d ud CSVCVC u d ud
        cv(T) U/VC U/VC U/VC cv(T) U/VC U/VC U/VC cv(T) U/VC X U/VC
        cv(M) U/VC D/CS U/VC cv(M) U/VC D/VB U/VC cv(M) U/VC D/VC U/VC
        cv(B) U/VC D/CS U/VC cv(B) U/VC D/VB U/VC cv(B) U/VC D/VC U/VC
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/VC D/CS U/VC ctv(B) U/VC D/VB U/VC ctv(B) U/VC D/VC U/VC

        VisualBasic Client

        The 9 first tables for the VisualBasic exe. On each line of 3 tables only the second librairy (Down) changes.
        Sémantique VB
        Results are conform to VB semantics but for slot (1,2) and slot (6,2) when Down is programmed in C++ that triggers a compilation error or find in Down instead of Up respectively.
        Table B is a simplified presentation of these results (where language signature is used as results).
         

        Tables 23 : VB as Client and CS for Up, Top, Middle Bottom
        VBCSCS u d ud VBVBCS u d ud VBVCCS u d ud
        cv(T) U/CS U/CS U/CS cv(T) U/CS U/CS U/CS cv(T) U/CS X U/CS
        cv(M) U/CS D/CS U/CS cv(M) U/CS D/VB U/CS cv(M) U/CS D/VC U/CS
        cv(B) U/CS D/CS U/CS cv(B) U/CS D/VB U/CS cv(B) U/CS D/VC U/CS
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/CS U/CS U/CS ctv(B) U/CS U/CS U/CS ctv(B) U/CS D/VC U/CS
        Tables 24 : VB as Client and Up, Top, Middle Bottom
        VBCSVB u d ud VBVBVB u d ud VBVCVB u d ud
        cv(T) U/VB U/VB U/VB cv(T) U/VB U/VB U/VB cv(T) U/VB X U/VB
        cv(M) U/VB D/CS U/VB cv(M) U/VB D/VB U/VB cv(M) U/VB D/VC U/VB
        cv(B) U/VB D/CS U/VB cv(B) U/VB D/VB U/VB cv(B) U/VB D/VC U/VB
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/VB U/VB U/VB ctv(B) U/VB U/VB U/VB ctv(B) U/VB D/VC U/VB
        Tables 25 : VB as Client and C++ for Up, Top, Middle Bottom
        VBCSVC u d ud VBVBVC u d ud VBVCVC u d ud
        cv(T) U/VC U/VC U/VC cv(T) U/VC U/VC U/VC cv(T) U/VC X U/VC
        cv(M) U/VC D/CS U/VC cv(M) U/VC D/VB U/VC cv(M) U/VC D/VC U/VC
        cv(B) U/VC D/CS U/VC cv(B) U/VC D/VB U/VC cv(B) U/VC D/VC U/VC
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/VC U/VC U/VC ctv(B) U/VC D/VB U/VC ctv(B) U/VC D/VC U/VC

        C++ Client

        The 9 first tables for the C++ exe. On each line of 3 tables only the second librairy (Down) changes.
        Results are conform to C++ semantics but for slot (6,2) when Down is programmed in C#!
        Table C is a simplified presentation of these results (where language signature is used as results).
         

        Tables 26 : VC as Client and CS for Up, Top, Middle Bottom
        VCCSCS u d ud VCVBCS u d ud VCVCCS u d ud
        cv(T) U/CS X U/CS cv(T) U/CS X U/CS cv(T) U/CS X U/CS
        cv(M) U/CS D/CS U/CS cv(M) U/CS D/VB U/CS cv(M) U/CS D/VC U/CS
        cv(B) U/CS D/CS U/CS cv(B) U/CS D/VB U/CS cv(B) U/CS D/VC U/CS
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/CS U/CS U/CS ctv(B) U/CS U/CS U/CS ctv(B) U/CS U/CS U/CS
        Tables 27 : VC as Client and VB for Up, Top, Middle Bottom
        VCCSVB u d ud VCVBVB u d ud VCVCVB u d ud
        cv(T) U/VB X U/VB cv(T) U/VB X U/VB cv(T) U/VB X U/VB
        cv(M) U/VB D/CS U/VB cv(M) U/VB D/VB U/VB cv(M) U/VB D/VC U/VB
        cv(B) U/VB D/CS U/VB cv(B) U/VB D/VB U/VB cv(B) U/VB D/VC U/VB
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/VB D/CS U/VB ctv(B) U/VB D/VB U/VB ctv(B) U/VB D/VC U/VB
        Tables 28 : VC as Client and Up, Top, Middle Bottom
        VCCSVC u d ud VCVBVC u d ud VCVCVC u d ud
        cv(T) U/VC X U/VC cv(T) U/VC X U/VC cv(T) U/VC X U/VC
        cv(M) U/VC D/CS U/VC cv(M) U/VC D/VB U/VC cv(M) U/VC D/VC U/VC
        cv(B) U/VC D/CS U/VC cv(B) U/VC D/VB U/VC cv(B) U/VC D/VC U/VC
        ctv(T) X X X ctv(T) X X X ctv(T) X X X
        ctv(M) X D/CS X ctv(M) X D/VB X ctv(M) X D/VC X
        ctv(B) U/VC D/CS U/VC ctv(B) U/VC D/VB U/VC ctv(B) U/VC D/VC U/VC

        .NET faces a real problem. Component are not substituable if they are programmed in different languages...


        A simplified presentation of the language interaction is shown in Table A, B and C. We use language signatures (when possible) as results.
        See C#, Visual Basic, C++ signatures.

        In table A, the client is in C#. The framework languages are in the columns. The extension languages (for Down) are in lines. It is a simplification of Table 19, 20 and 21.

        Tables A : C# as Client
        Extension\Framework C# VB C++
        C# C# C# C++
        VB C# C# C++
        C++ C# C# C++

        In table B, the client is in Visual Basic. The framework languages are in the columns. The extension languages (for Down) are in lines. It is a simplification of Table 22, 23 and 24.

        Tables B : Visual Basic as Client
        Extension\Framework C# VB C++
        C# VB VB C++
        VB VB VB C++
        C++ VB C# C++

         

        In table C, the client is in C++. The framework languages are in the columns. The extension languages (for Down) are in lines. It is a simplification of Table 25, 26 and 27.
        Note that the first line has a signature which is not one of studied languages (Ada95, C++, C#, CLOS, Dylan, Eiffel, Java, nice, OCaml, Python, Scala, Smalltalk, Visual Basic).

        Tables C : C++ as Client
        Extension\Framework C# VB C++
        C# VB/C++ VB/C++ VB/C++
        VB C++ C++ C++
        C++ C++ C++ C++


        As a temporary conclusion, we can say that the only way to build a component that always answer as the client expect is to write the framework/extension with the following couple : C#/VB, C#/C++ and VB/VB !! (the dark green slots that are always equal to the client language...).


        7. Code transformation

        In order to simulate the reasonable semantics, it is possible to program the test suite less naively, using explicit casting or type testing...


        8. Conclusion

        OO programming may seem natural and easy. Once inheritance is understood everything is clear! sure? I hope these experiments and tables ask questions ...
        The proposed tables could be considered as a "language signature" from the late-binding semantics. An idea to explore is how language signatures could be used to forecast interactions of different languages...

        To become mature OO paradigm needs a unified semantics and not only a unified notation...the UML Action Semantics is one step forward, but still remain confusing on the meaning of the lookup procedure which is, to my opinion, the key point of OO semantics. [Beu02-3] makes somme proposals.

        I propose two semantics: a reasonable semantics, that offers the best specialization and good continuity properties (when we consider multiple late-binding) and a pragmatic one, with "lesser good" properties, but closer to many popular languages, and therefore a good candidate. C# implements it and a small and incremental change in the compiliers of C++ and Java could make all these three languages adopting the same late-binding behavior.

        The last conclusion that comes from the observation of tables A, B and C is the following : are components compatible with the object paradigm?

        Considering the most recen results, my position is now to restrict OO programming languages to a strict invariance redefinition and overriding forbidance. As for structuring languages it has been useful to limit the use of the GOTO, I consider that for allowing OO language interoperability it is necessary to restrict the use of overriding and overloading.

        Future work (I'm looking for funding :-):

        1. The most pertinent (low cost, minimal research) approach to make languages dynamically interoperable seems to adopt the pragmatic semantics and to make C++ accept to compile slot (1,2) and java slot (6,2). This very little semantics shift would lead to a unification af C#, C++ and Java behavior...
        2. Another approach consists in selecting a pivot semantics (pragmatic or reasonable) and to program and model using this common semantics. Then different compilers will generate the target language code corresponding to the unified semantics - with all explicit cast required ! UML/Action Semantics could adopt this strategy.
        3. Accepting diversity, and trying to better undestand late-binding language interaction...using "signature operators"...

        Thanks

        Special thanks to Olivier Aubert who contibutes for Python and to Martin Monperrus who contributes for Ruby.
        And to Roger Rousseau for the Eiffel code transformation used to make Eiffel match the "reasonable semantics".
        Thanks to Howard Lovatt for the interesting discussions we have and the suggestions he made.
        Thanks  to Tobias Wahl for detecting the Java semantics change from 1.3  to 1.4.

        Références

        [Beu02-1] Antoine Beugnard, "OO languages Late-binding Signature", accepted at FOOL 9 (The Ninth International Workshop on Foundations of Object-Oriented Languages) , Portland, Oregon, january 19, 2002.
        [Beu02-2] Antoine Beugnard, "Une comparaison de langages objet relative au traitement de la redéfinition de méthode et à la liaison dynamique", LMO 2002, Montpellier, 23-25 janvier 2002.
        [Beu02-3] Antoine Beugnard, "Is UML Action Semantics precise enough? Can Software Engineering do without semantics?", submitted to ICSE 2002
        [Beu05] Antoine Beugnard, "Peut-on réaliser des composants avec un langage à objets ?", LMO 2005, Berne, 9-11 mars 2005.
        [Beu06] Antoine Beugnard, "Method overloading and overriding cause encapsulation flaw", Object-Oriented Programming Languages and Systems, 21st ACM symposium on  Applied Computing (SAC), Dijon, France, Appril 23-27 2006.
        [CM05] Gareth Carter and Rosemary Monahan, "Software Specification, Implementation and Execution with Perfect", Technical Report, National University of Ireland, Maynooth Maynooth, Co Kildare, Ireland, Department of computer science, technical report series, NUIM-CS-TR-2005-07, 2005

        updated the 26 may 2011
        by Antoine Beugnard, IMT Atlantique