Before I create another helper .p, is there a way to call a class method by its name?
I think this was discussed on a different forum recently ... possibly the OO one, where it seems it should belong. There is a dynamic NEW for instantiating objects dynamically, but not a dynamic method call. In many ways the whole idea of a dynamic method call is anti-OO. It is certainly reasonable to define an interface shared by a number of classes in some set and then to instantiate one of those classes and use the knowledge of the interface to make calls ... in fact, that is a highly recommended practice, but actual dynamic method calls runs counter to the whole idea of compile time checking, defined interfaces, etc.
If you are asking the question on this forum because the clases in question are .NET and thus not in your control, then add a wrapper which uses the common interface.
jquerijero wrote:
Before I create another helper .p, is there a way to call a class method by its name?
Assuming you mean type invocation, up to (and including) 10.2A:
def var objRef as MyIFace.
def var cTypeName as char.
cTypeName = "Type.Implements.MyIFace".
objRef = dynamic-new(cTypeName) ().
The 10.2B Beta extends this via
-- peter
The OP said "class method".
tamhas wrote:
The OP said "class method".
Indeed he did. Then only the latter part of my post is valid.
-- peter
Yeah, but now you have given him hope and I'd rather talk him out of wanting to do it!
Hah .
I certainly agree with the use of strong typing as far as possible, for the reasons you laid out earlier.
-- peter
The key, I think, is that there are some very sound design principles behind good OO practice and wanting to do things like run dynmic methods is an almost sure indication that those principles are not being observed. There *are* good reasons for some of this kind of thing buried in a framework ... just like one does fancy stuff in writing operating systems that one would never want someone to do in application code. But, otherwise, one should take the urge to want to do such things as a sign that one has not thought about the problem clearly.
We have quite a few data-driven procedure and internal procedure calls in our legacy Progress that needs to be converted to GUI for .NET. Support for something like .NET Reflection would have sufficed but that just me dreaming.
As for dynamics method call, it has nothing to do with OO programming paradigm. It's a programming language feature.
Moving your exisitng code to AG4.N is a perfect opportunity to stop and ask whether or not you are doing things the right way or might there be a better solution. Yes, I understand the problem of having to live with existing infrastructure ... lots of experience in that realm, but I still find it useful to step back and figure out what I *should* be doing and try to do that as much as possible. There are lots of things that people did in earlier versions which I would not encourage them to bring forward into later versions. And, yes, it is an OO issue. Why bother using OO at all if you aren't going to use it well and get the benefits?
It is one thing to bury this kind of stuff in a framework component and another to sprinkle it around the application.
I'm always concerned when I hear the request for dynamic method invocation. I'd rather think of a different design. Usually using Interfaces.
As for dynamics method call, it has nothing to do with OO programming paradigm. It's a programming language feature.
Can you explain this. I don't understand what you're saying. Strong typing is a programming paradigm. Dynamic method invocation breaks that paradigm.
It seems to me to be the contrast between thinking that doing OO means using the ABL language elements for OO versus doing OO being adhering to an OO paradigm, even if writing old .ps.
Nonetheless, Planned for 10.2B:
Dynamic Object Invocation provides the ability for an ABL application to invoke a method whose name is not known until runtime. Two facilities have been added to the ABL to provide this capability. In one facility the parameters for the dynamically invoked methods are specified at compile time while in the other the parameters are specified at runtime.