sap.ui.model.Model.prototype.createBindingContext return type are wrong #379

Activity

1. akudev commented on Sep 27, 2022

   

   akudev

   on Sep 27, 2022

   Member

   More actions

   Hm. The situation is like this:
   

   • v2.ODataModel code returns undefined or null (or a context, of course; and claims it returns context or undefined)
   • v4.ODataModel returns always a context, apparently (and claims so)
   • the original ODataModel returns undefined or null (and claims @see Model)
   • ClientModel returns null (and claims @see Model)
   • model.MetaModel returns null (and claims @see Model)
   • Model is abstract and claims it returns undefined

   So what exactly is your request? that the base class "Model" should document the return type as "null" instead of "undefined"? (the one in error case of course) That would seem to make sense.

   Or that in addition the the original ODataModel admits it might also return "undefined" and the v2.ODataModel admits it might also return "null"??
2. codeworrior commented on Sep 28, 2022

   

   codeworrior

   on Sep 28, 2022

   Member

   More actions

   @uhlmannm and @pksinsik can you please take a look at this? V4 never returning null or undefined is okay for TypeScript, but the others should align on a signature that they inherit from the base class.

   I would assume that for the widely used models, compatibility "rulz". Extending the base signature to both, undefined and null might be the only way to fix this. But maybe you're more optimistic reg. a leaner solution (e.g. as v2 ODataModel does not document the null, can it replace it with undefined?).
3. nlunets commented on Sep 28, 2022

   

   nlunets

   on Sep 28, 2022

   ContributorAuthor

   More actions

   So what exactly is your request? that the base class "Model" should document the return type as "null" instead of "undefined"? (the one in error case of course) That would seem to make sense.

   I wish for every model to confirm what they return properly at least :) so yes returning null instead of undefined feels better.

   Regarding v4, it actually throws error when something is not ok which might be contrary to the philosophy of the models in general.
4. pksinsik commented on Sep 28, 2022

   

   pksinsik

   on Sep 28, 2022

   More actions

   @codeworrior We should not change the cases where v2.ODataModel#createBindingContext returns null to return undefined; same is true for ClientModel. Reason is - compatibility...
   If you say TypeScript really requires it we may enhance the return value documented for Model#createBindingContext.
5. akudev commented on Sep 28, 2022

   

   akudev

   on Sep 28, 2022

   Member

   More actions

   If you say TypeScript really requires it we may enhance the return value documented for Model#createBindingContex

   Isn't correctness also a good reason to change documentation?
6. pksinsik commented on Sep 29, 2022

   

   pksinsik

   on Sep 29, 2022

   More actions

   we will work on the topic "fix jsdoc for null value for a context resp. optional oContext parameters across APIs for base model, client models, v2.ODataModel classes" via the existing incident 2270138264 already opened by @nlunets