mORMot Open Source

radexpol

Member

From: Poland, Krk

Registered: 2019-11-29

Posts: 116

SOA - Return object

How to deal with objects especially their livetime.

type
  TIVRSettings = class
  published
    PROMPT: TPROMPT; //TInterfacedCollection
    PHONE_NUMBER: TPHONE_NUMBER; //TInterfacedCollection
    PARAMETER: TPARAMETER; //TInterfacedCollection
  end;

  IVRSettings = interface(IInvokable)
    ['{DFA6783D-7C30-4CC2-B9F3-9D73147F302B}']
    function GetVRSettings(out IVRSettings: TIVRSettings): TResponse;
  end;

  TSirenIntegration = class(TInterfacedObject, IVRSettings)
  private
    function GetVRSettings(out IVRSettings: TIVRSettings): TResponse;
  end;

procedure TSirenIntegration.GetVRSettings(out IVRSettings: TIVRSettings): TResponse;
begin
  IVRSettings:= TIVRSettings.create -> how about free?
end

should I inherit TIVRSettings from any autofree class such as TInterfacedObject (and implement an interface).

radexpol

Member

From: Poland, Krk

Registered: 2019-11-29

Posts: 116

Re: SOA - Return object

Let me answer myself.

The "out" class instance will be automatically created be internal mechanism, no need to manually instance the object.

That's pity that mormot is so poor documented, no information about TPersistentWithCustomCreate, no simple samples in documentation, use cases. Searching for this forum takes a long hours or days to find a solution every time I have to implement new feature or even data type such as TPersistentWithCustomCreate.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,548

Website

Re: SOA - Return object

TPersistentWithCustomCreate is not different to plain TObject/TPersistent in respect to interface-based services.
It is documented as https://synopse.info/files/html/api-1.1 … STOMCREATE

So the default convention and memory allocation detailed in the main documentation apply:
https://synopse.info/files/html/Synopse … #TITLE_406

So every TObject parameter instance shall be managed by the caller, i.e. allocated before the call and released after it.

There is an explanation, at the end of this paragraph, about why it is as such.

So this requirement/limitation was designed as such to make the server side more resilient to errors, even if the client side is a bit more complex to work with. Usually, on the client side, you can safely pre-allocate your object instances, and reuse them.

I understand it may be confusing, and that the documentation is not perfect.
Sorry if you were confused. But TPersistentWithCustomCreate by itself is nothing different than a TPersistent with a virtual constuctor. Nothing more to detail.