Hello,

Is there a way to tell in run-time that a specific function/procedure should belong to a class ?

For example, let's say I have the following class:

Type
  TTest = class
    procedure Foo;
  end;

And I have also:

procedure Bar;
...
end;

Is there a way to make at some point of my code execution, that Bar will be a method of TTest ?
Or maybe for a specific instance of TTest ?

Thanks,

Ido

As far as I know there is no language structure for this, unless the objective C classes support offers this.

Michael.

michael.vancanneyt wrote on Tue, 19 Jun 2012:

As far as I know there is no language structure for this, unless the objective C classes support offers this.

You can indeed do that in Objective-C/Pascal, but
a) that's not via a language construct, but by directly interacting with the runtime via helpers from libobjc (both in Objective-C and in Objective-Pascal)
b) FPC only supports Objective-Pascal on Mac OS X/iOS at this time

Jonas

ik hat am 19. Juni 2012 um 14:22 geschrieben:

Do you mean that TTest.MethodAddress('bar') should return your Bar?

Yes.

Mattias

On Tue, Jun 19, 2012 at 4:13 PM, Mattias Gaertner <

Yes, after "adding it" (glue) to the TTest class/instance. Like with some dynamic languages that allow you to create/attach methods on run time.

Yes.

Depending on what you’re actually trying to do, you may consider implementing your own invokable variant type. I found a tutorial at http://alex.ciobanu.org/?p=152. Basically, instances will be wrapped in a TVarData-compatible record, and your custom
TInvokeableVariantType-derived class will allow you to intercept method calls.

Class helpers would not help ?

http://wiki.freepascal.org/Helper_types

-Laco.

They can, but there is a protocol that I'm trying to create that provides me information what to execute (out of white list). The thing is, that the first request maps the methods to be used, and there could be 2 or 200. To implement 200 methods that might be used is not a good idea imho, but adding the proper method to the instance/class will work much better.

It's easy to do in dynamic language, and I might need to implement it there instead :(

I don't understand this argument. The available methods must have an implementation somewhere anyway. That means your code does not get smaller by adding them dynamically. Somewhere you must choose which method to execute, and whether it is allowed or not, so this logic must be present also. None of this requires dynamically adding methods as far as I can see, or is made easier by dynamically adding methods.

So finally, what is gained by adding them dynamically ? Or what forces you to even consider this path ?

Michael

They can, but there is a protocol that I'm trying to create that provides me information what to execute (out of white list). The thing is, that the first request maps the methods to be used, and there could be 2 or 200. To implement 200 methods that might be used is not a good idea imho, but adding the proper method to the instance/class will work much better.

It's easy to do in dynamic language, and I might need to implement it there instead :(

Can't you create a stub that executes your variable methods/functions? Something like

Type
  TTest = class
    procedure Foo;
    procedure NewMethod(MethodName:string;
MethodAddress:TProcedureOfObject);
    procedure Call(MethodName:string)
  end;

NewMethod stores the name + method address in fe. a StringList. Call just looks up the method and executes it. The method will receive the Self of the TTest instance which is what you want.

Ludo

Think of a plug-able system. I have an engine, and code to execute. Instead of compile everything to an ELF/PE, I place code on dynamic shard library, and load it on run time when needed.

The idea is that the engine will not be rewritten for every new request (that comes often), because it's logic (almost) never changes, but to load code on demand that often changes, provide additional functions, changes of logic, bug fixes etc...

The idea of implementing it like so, came to me after few years now of having the need to recreate the whole logic based of the code for every new demand from the client (both as human, and as software). The main code almost never changes, but so many additions, that I'm starting to use the dynamic execution of methods, and now I realize, that if I'll extract it to a shard library, it will be much easier to change, add etc... only the actual need, and not to touch other stuff, and that requires me to design an engine instead.

Regardless of that idea, it can be very interesting in learning how to do it imho :)

Michael

Ido

I suggest that you implement this using interfaces. You place the interface declaration in a common file, use the interfaces from the main exe but implement them in separate dlls. This gives you all the flexibility you want, e.g. group your methods into bundles and place them on different interfaces. You will only need a class identifying system (i.e. a "class id" string) that will be known to the exe and implementing dlls and a "factory" exported function in each dll that creates the implementing object of a known "class id". You can have many alternate implementations of an interface with different class ids and you can even replace an implementing dll with another version of it with bug fixes or even different functionality.

In my mind it is always <Plugin System> ==> Interfaces.

HTH.

This is understandable, but none of this explains why you would need to add a method to a class ? I have a similar system, but do not need to add methods to a class ?

Michael.

In our previous episode, kyan said:

I suggest that you implement this using interfaces. You place the interface declaration in a common file, use the interfaces from the main exe but implement them in separate dlls.

Or maybe go a step further, and use IDispatch that passes through unknown methods to handler functions in the loaded dynamic libraries.

This will also allow some freedom in the parameter lists of added functions.

WST library server implementation could be a elegant solution : it is web-services that are
locally located in dynamic library(DLL)/shared object(so) instead of being remote. The main
executable acts as client while the server's implementation as provided as shared objects.
No TCP is used, only memory through the WST's library protocol. No SOAP serialization
as you can use the WST's custom binary messaging format that is very fast.

To resume :
* The main executable defines a WSDL schema that contains the types (think of this as IDL)
* The servers implement the service exposed in the schema.
* The main executable loads the servers using the library protocol

Main benefits are :
* much larger type system available (wsdl, WST contains a type library editor)
* you could later even add remote servers without changing your main application,
just create the service with the desired location parameters.

Thank you, I'll check it out. My "problem" is something like with WDSL idea.

Ido

_______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Use event properties (Properties to a procedural type)

Adding completely free methods to a class makes no sense.

By free i mean a method that has no clear signature (parameters and result type) because calling them will be a nightmare (You will have to do the compiler work and build your own parameter passing and return type system).

This is usually done in interpreters but what you describe doesnt sound like a interpreter.

2012/6/21 ik :