Do not report G-7440 when in out is used for self as part of a fluent API

[DavidotNet]

Type OBJECT syntax requires use of IN OUT, (I think) in this case syntax should not be flagged with
G-7440: Never use OUT parameters to return values from a function.

create or replace TYPE shape as object
(
name varchar2(30 char)
, area number

, constructor function shape(self in out nocopy shape
, in_name varchar2
, in_area Number) return self as result

, member function Updatee(self in out nocopy shape
, in_name in varchar2) return boolean
);
/
create or replace type body shape
as
constructor function shape (in_name varchar2
, in_area number) return self as result is
begin
self.name := in_name;
self.area := in_area;
return;
end;

member function Updatee(self in out nocopy shape
, in_name in varchar2) return boolean
is
begin
self.name := in_name;
return true;
end;
end;

[PhilippSalvisberg]

You're correct that self requires to be passed either as in or as in out.

In a constructor function, you have no choice but to use in out. In that case case, we do not throw a G-7440 violation.

However, in other member units, you have a choice. Nobody forces you to use a member function. You could (and should) use a member procedure as in the following amended example of yours:

create or replace type shape as object
(
   name varchar2(30 char),
   area number,

   constructor function shape(self in out nocopy shape,
                              in_name            varchar2,
                              in_area            number) return self as result,

   member procedure updatee(self    in out nocopy shape,
                            in_name in            varchar2)

);
/

create or replace type body shape
as
   constructor function shape(in_name varchar2,
                              in_area number) return self as result is
   begin
      self.name := in_name;
      self.area := in_area;
      return;
   end;

   member procedure updatee(self    in out nocopy shape,
                            in_name in            varchar2)
   is
   begin
      self.name := in_name;
   end;
end;

In this amended example no G-7440 violation is thrown.

[DavidotNet]

An Object contains behavior methods which perform operations on SELF including changes to member attributes; the object state. For both internal (private) methods and external client callers, the caller does not code the Object as a parameter. SELF is implied; it is not physically coded by the external caller as a parameter.

In my Stored Procedure code - the array item 'Name1' is either updated or replaced with new Object state.

Client
aa_Associative_Array( Name1 ) := myObject.Updatee( in_value1, invalue2 ); --function result

As suggested, it is my choice how to design the object method signiture. I could pass the Object as a procedure IN OUT parameter. My Stored Procedure code would look like this.

Client
object.Updatee( in_value1, in_value2, myObject ); --Procedure method
aa_Associative_Array( Name1 ) := myObject;

That would work; however, it is in my opinion, not an elegant coding style as is the first example which more closely resembles C# or Java. The concept of object-oriented programming is different from the usual PLSQL syntax in that, one doesn't pass the object as a parameter but instead writes code using the object dot (.) notation as in:

Object
member function Updatee( SELF IN OUT, . . . ) return self as result . . .

Client
sys.dbms_output.put_line**(** aa_Associative_Array( Name1 )**.**Updatee( in_value1, in_value2 ) ); _--The function result is printed. _

Best practices suggested by G-7440 are applicable to normal PLSQL functions. However, as the object type concept and syntax are different (not passing SELF as a parameter by client), so should the application of G-7440 be treated differently in the case of Object types. That's my opinion.

And, thank you for your excellent db CodeCop tool.

[PhilippSalvisberg]

Ok, I see that reporting a G-7440 when building a fluent API is a false positive. In an example like this (returning the object type shape and not a boolean like in your example):

   member function set_name(self in out nocopy shape, in_name in varchar2) return shape is
   begin
      self.name := in_name;
      return self;
   end;

I'll consider changing the validator check to handle this exception. Therefore I move this issue to the CLI repo, where the checks are managed.

[PhilippSalvisberg]

closed with Azure DevOps commit f26d718a87e8bfbf3227a08d4df6dce8610d3740

(G-7440 is not reported for parameters named "self")