Skip to main content

Public

Project privacy set to public. By default, its content is available to everyone (authenticated or not). Please note that more restrictive permissions might exist on some items.

    •  
      request #15020 REST representations can be hydrated even when they define a constructor
    Actions
    Infos
    #15020
    Thomas Gerbet (tgerbet)
    2020-07-16 15:55
    2020-06-25 14:03
    16270
    Details
    REST representations can be hydrated even when they define a constructor
    As of today the framework used by Tuleap to manage the REST API does make possible to define a constructor with parameters (or to mark the constructor as private) on a representation that is hydrated by the framework (i.e. all representations used to represent the parameters of a REST endpoint).

    Until now, Tuleap has workaround the issue with a non static build() method on these representations.

    This is not great for a multitude of reasons:
    * there is no way to ensure the developer actually call the build method after having instantiated the representation. It means it's possible to break the contract said by that said representation.
    * SA complains about it because determining if the variable has been initialized is hard
    * it prevents using annotations like `@psalm-readonly` or `@psalm-immutable`
    * it is not the standard way to initialize properties of an object, this can be unsettling for a newcomer has she needs to understand why in this situation (and only this one) it's okayish to do that but not elsewhere
    API
    Empty
    Empty
    • [ ] enhancement
    • [x] internal improvement
    Empty
    Stage
    Thomas Gerbet (tgerbet)
    Closed
    2020-07-16
    Attachments
    Artifact links

    Releases

    Fixed in

    Artifact ID Project Tracker Summary Status Last Update Date Submitted By Assigned to
    rel #14817 Tuleap Releases 11.17 Delivered 2020-23-07 10:57 Manuel Vacelet (vaceletm)
    Empty
    References
    Referencing request #15020

    Artifact Tracker v5

    request #15111 REST representations should not be mutable

    Git commit

    tuleap/tuleap/stable

    Merge commit 'refs/changes/36/19336/2' of ssh://gerrit.tuleap.net:29418/tuleap into HEAD 3440fa55c1
    User avatar Nicolas Terray (nterray) , 2020-07-01 15:55
    request #15020: REST representations can be hydrated even when they define a constructor 484c105c98
    User avatar Thomas Gerbet (tgerbet) , 2020-07-01 15:07
    Referenced by request #15020

    Artifact Tracker v5

    rel #14817 11.17

    Other

    gerrit #19336
    Display settings

    Follow-ups

    User avatar
    Manuel Vacelet (vaceletm)2020-06-25 17:34

    However once we have this first step it becomes possible to force via a Psalm plugin that all DTOs used in the REST endpoints are immutable and only have public properties.

    Will you marry me ?

    User avatar
    Thomas Gerbet (tgerbet)2020-06-25 17:28
    As a first step I cannot but it's still better than what we have today where we cannot assume anything at all about the state.

    However once we have this first step it becomes possible to force via a Psalm plugin that all DTOs used in the REST endpoints are immutable and only have public properties. This is not something we can currently do because we mutate the state.
    User avatar
    Manuel Vacelet (vaceletm)2020-06-25 17:17

    How will we ensure that we are only dealing with DTO ?

    As far as I understand you are making use of a lib that workaround the constructor to instanciate the object. My main concern is that if constructor contains logic for init we will break the assumptions dev can make about the state of the object.