RTTI Integration #3

Open
opened 2025-07-29 03:54:17 +00:00 by JernejL · 5 comments
JernejL commented 2025-07-29 03:54:17 +00:00 (Migrated from github.com)

Is there an example of pascal app integration - exposing pascal classes via RTTI or registering global methods like in besen?

Is there an example of pascal app integration - exposing pascal classes via RTTI or registering global methods like in besen?
JernejL commented 2025-08-05 05:21:56 +00:00 (Migrated from github.com)

Seems like the only example how to expose a class inside poca is in POCARunCore.pas:

class is extended from TPOCANativeObject type TRandomNumberGenerator=class(TPOCANativeObject) (similar to how besen is from TBESENNativeObject)

instead of RegisterNativeObject there is:

POCAHashSet(Context,Instance.Globals.Namespace,POCANewUniqueString(Context,'RandomNumberGenerator'),POCANewNativeObject(Context,TRandomNumberGenerator.Create(Instance,Context,nil,nil,false)));

and the magic create method equivalent to besen's ConstructObject is create_:

function TRandomNumberGenerator.create_(const Context:PPOCAContext;const This:TPOCAValue;const Arguments:PPOCAValues;const CountArguments:longint):TPOCAValue;

Seems like the only example how to expose a class inside poca is in POCARunCore.pas: class is extended from TPOCANativeObject type TRandomNumberGenerator=class(TPOCANativeObject) (similar to how besen is from TBESENNativeObject) instead of RegisterNativeObject there is: `POCAHashSet(Context,Instance.Globals.Namespace,POCANewUniqueString(Context,'RandomNumberGenerator'),POCANewNativeObject(Context,TRandomNumberGenerator.Create(Instance,Context,nil,nil,false)));` and the magic create method equivalent to besen's ConstructObject is create_: `function TRandomNumberGenerator.create_(const Context:PPOCAContext;const This:TPOCAValue;const Arguments:PPOCAValues;const CountArguments:longint):TPOCAValue;`
BeRo1985 commented 2025-10-28 16:08:07 +00:00 (Migrated from github.com)

As a small side note: I have extended the TPOCANativeObject class so that it can now also include "foreign" classes with its RTTI functionality. This should make it easier to expose existing Pascal classes without having to derive them from TPOCANativeObject directly. :-)

As a small side note: I have extended the TPOCANativeObject class so that it can now also include "foreign" classes with its RTTI functionality. This should make it easier to expose existing Pascal classes without having to derive them from TPOCANativeObject directly. :-)
JernejL commented 2025-10-30 13:21:48 +00:00 (Migrated from github.com)

Ok, but what part does this support? properties, methods?

Still.. a good example for usage for this would be very helpful.

Ok, but what part does this support? properties, methods? Still.. a good example for usage for this would be very helpful.
BeRo1985 commented 2025-10-30 14:26:55 +00:00 (Migrated from github.com)

For both properties and methods, you can use this pattern. Here's an example:

type TMyUseFulClass=class
      private
       fMyProperty:TPOCAInt32; 
      published 
       function MyMethod(const Context:PPOCAContext;const This:TPOCAValue;const Arguments:PPOCAValues;const CountArguments:TPOCAInt32):TPOCAValue;
       property MyProperty:TPOCAInt32 read fMyProperty write fMyProperty;
     end;

where you can use AddObject of TPOCANativeObject to include this "foreign" class in your POCA module, without being derived from TPOCANativeObject itself. In this way, you can encapsulate useful functionality in separate classes and expose them to POCA scripts, without needing to inherit from TPOCANativeObject directly.

Speaking of usage, you can do something like this:

var MyUseFulClassInstance:TMyUseFulClass;
    ExampleNativeObject:TPOCANativeObject;
begin
 MyUseFulClassInstance:=TMyUseFulClass.Create;
 try
  ExampleNativeObject:=TPOCANativeObject.Create;
  try
   ExampleNativeObject.AddObject(MyUseFulClassInstance);
   // The actual POCA code stuff here
  finally
   ExampleNativeObject.Free;
  end;
 finally
  MyUseFulClassInstance.Free;
 end;
end;

but attention: the ownership of MyUseFulClassInstance is not transferred to ExampleNativeObject, so you need to manage its lifetime separately, as shown in the example above. So it isn't freed when ExampleNativeObject is freed, and also not garbage collected by POCA. This is important to avoid memory leaks or dangling pointers. But in this way, you can have "foreign" classes integrated into POCA modules easily.

For both properties and methods, you can use this pattern. Here's an example: ```pascal type TMyUseFulClass=class private fMyProperty:TPOCAInt32; published function MyMethod(const Context:PPOCAContext;const This:TPOCAValue;const Arguments:PPOCAValues;const CountArguments:TPOCAInt32):TPOCAValue; property MyProperty:TPOCAInt32 read fMyProperty write fMyProperty; end; ``` where you can use `AddObject` of TPOCANativeObject to include this "foreign" class in your POCA module, without being derived from TPOCANativeObject itself. In this way, you can encapsulate useful functionality in separate classes and expose them to POCA scripts, without needing to inherit from TPOCANativeObject directly. Speaking of usage, you can do something like this: ```pascal var MyUseFulClassInstance:TMyUseFulClass; ExampleNativeObject:TPOCANativeObject; begin MyUseFulClassInstance:=TMyUseFulClass.Create; try ExampleNativeObject:=TPOCANativeObject.Create; try ExampleNativeObject.AddObject(MyUseFulClassInstance); // The actual POCA code stuff here finally ExampleNativeObject.Free; end; finally MyUseFulClassInstance.Free; end; end; ``` but attention: the ownership of `MyUseFulClassInstance` is not transferred to `ExampleNativeObject`, so you need to manage its lifetime separately, as shown in the example above. So it isn't freed when `ExampleNativeObject` is freed, and also not garbage collected by POCA. This is important to avoid memory leaks or dangling pointers. But in this way, you can have "foreign" classes integrated into POCA modules easily.
JernejL commented 2025-10-31 08:24:10 +00:00 (Migrated from github.com)

Is there a chance that RTTI is also used for invoke calls - so that it is not array of PPOCAValues?

This is a major issue with besen as well. i wrote a code generator ( https://github.com/JernejL/besen_interface_generator ) to generate these in order to easily interface from script to native code & back.

Is there a chance that RTTI is also used for invoke calls - so that it is not array of PPOCAValues? This is a major issue with besen as well. i wrote a code generator ( https://github.com/JernejL/besen_interface_generator ) to generate these in order to easily interface from script to native code & back.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
BeRo1985/poca#3
No description provided.