ABL : object reference from a character string

[DevTeam]

Hi,

Still doing a comparison between our 4GL (bad according to tamhas) habits and ABL-OO possibilities, and I am wondering if there's an equivalent for the HANDLE function, that is to say retrieving an object instance from a given character string.

Former code :

PROCEDURE myProc :
  DEF INPUT PARAMETER strHndl AS CHAR NO-UNDO.
  DEF VAR hndl AS HANDLE NO-UNDO.

  hndl = HANDLE(strHndl).
  
  IF VALID-HANDLE(strHndl)
  THEN /* ... */
END PROCEDURE.

What I'd like to do :

METHOD PRIVATE VOID myProc (INPUT strHndl AS CHAR) :
  DEF VAR hndl AS CLASS myClass NO-UNDO.

  hndl = OBJECT(strHndl).  /* does not exist (yet ?) */
  
  IF VALID-OBJECT(strHndl)
  THEN /* ... */
END METHOD.

I searched the online documentation, but I couldn't find something equivalent.

Thanks in advance !

Julien

 

[tamhas]

Did you look up DYNAMIC-NEW?

 

[Casper]

I know from your previous posts that you are exploring ways to create a dynamic OO concept.
But the moment you try putting instances in character strings I think you are missing the points of having classes (or handles).
I miss the point of converting an object reference (or handle, now we speak of it) to a string and use that as a parameter.

Casper.

 

[DevTeam]

Did you look up DYNAMIC-NEW?

Hi Thomas,

Yes, I took a look at DYNAMIC-NEW, but it does not seem to work the way I am looking for. If I got it right, it allows the instantiation of a class at the execution time from its name, something like that :

myString = "myClassImpl".
DYNAMIC-NEW myString().

instead of

NEW myClassImpl().

 

[tamhas]

Err, the last one just looks like any normal class instantiation. Perhaps you need to say more about what you are trying to do.

But, Casper is right ... sounds like more attempts to abuse the system.

 

[DevTeam]

I know from your previous posts that you are exploring ways to create a dynamic OO concept.
But the moment you try putting instances in character strings I think you are missing the points of having classes (or handles).
I miss the point of converting an object reference (or handle, now we speak of it) to a string and use that as a parameter.

Casper.

Hi Casper,

There's no link between this post and the other ones. In the source code I am currently reading, it happens that server-side programs give their handle to each other through the client side. I'll try to explain it as clearly as I can :

Client.p  -------- RUN PERSIST ON SERVER -------> p1.p ---> p2.p
                                                  |
          <--------------p2's handle--------------|
  
            -------------------------------------> p3.p  ( so as to <--> p2.p )

Client.p runs p1.p on server, which runs p2.p persistently and returns p2's handle to Client.p as a character string.

Client.p runs p3.p on server and passes p2's handle-as-a-string as a parameter, so as to allow p3.p invoking p2's procedures...

Let's imagine we have objects instead of regular .p (and let's imagine it is possible to instantiate classes over C/S) : how to do the equivalent of HANDLE(p2-as-a-char) ?

 

[tamhas]

Well, I suppose you won't be surprised if I tell you that there are a number of things wrong here.

First, the whole concept you have outlined only works with a stateful appserver. That is bad practice to start with. You should be aiming for stateless or state free. You are locking down that AppServer client to a session and greatly reducing the scalability of the solution.

Second, passing back handles like this is inherently exposing the implementation across the AppServer boundary. Why in the world can the client possibly care about that handle and why not manage it entirely on the server side. The client should be asking for services and the server should be figuring out how it fulfills them. If you manage this on the server side, not only does the handle ... an inherently useless thing to the client since it is about the session on the server ... become unnecessary, but you are on your way to getting rid of the session lock.

Finally, even if there were some reason to pass such a thing back, which there isn't, it could be anything. Make a little temp-table on the server side with the procedures and a signature or identifier and pass back the identifier. No reason to, but it would let you do what you are doing now. If that identifier was a meaningful service name then you immediately are able to connect to *any* AppServer session. The session either has the service running already or can start it.

If you need to pass session data across the calls, either push it from the client with each call or create a context manager on the server side that persists this information in the database.

 

[DevTeam]

Indeed I'm not surprised...

But - even if you usually do not answer my questions - your posts are always interesting on an "how-it-would-be-better" point of view.

The point is : that's how our software currently works, and the purpose is not to "big-bang" it, but to see what could be the advantages of having classes instead of persistent procedures, what would be the minimum modifications to be done, and could it be made quite "automatically"...

So, would you have any idea about how to retrieve the actual object from its reference given as a char ?

 

[tamhas]

If one is starting off knowing that one's architecture is undesirable, I see no point in trying to add in objects. For starters, objects currently don't cross the AppServer boundary, so if you are passing any temp-tables or ProDataSets, you can't just plug in an object there and expect it to work. Instead, you would need to rethink the way that you are doing things in a way that fits with the way that objects work.

Rather than trying to shoehorn objects into your existing structure in some vague belief that will make something better, you should be thinking about how to evolve your system so that it is better. If you shoehorn objects into your existing structure, you won't be making any progress to a better architecture, just torturing OO concepts in ways that will need transformation should the context ever improve.

Transformation doesn't need to be a big bang. There are a number of techniques for evolving in a stepwise fashion to a more modern architecture, quite possibly starting in your case with a move to stateless. But, the real thing to do is to do an assessment up front of where you are, where you would like to go, and what the real business drivers are in that transition. With that, one can make a plan, create a target, develop strategies, and begin making incremental progress toward a better system.

 

[lord_icon]

The ABL is the 4GL, it is just an evolvement of the language.
The same is appropriate, there is no equivelant.

 

[DevTeam]

The ABL is the 4GL, it is just an evolvement of the language.
The same is appropriate, there is no equivelant.

If that's the same, you'll be able to show me how to manage what I'm asking for : get an instantiated object from its reference-as-a-char !

 

[tamhas]

What he means is that ABL is simply a rebranding of 4GL, not something new and different. However, as it did before the rebranding, the language continues to evolve so that which is possible in one version is not possible in versions previous to it, although PSC has done a remarkable job of providing upward compatability.

In implementing the OO extensions to ABL, PSC decided, I think wisely, to adhere to a fairly strict sense of OO, although, of course, not everything made it into the first release and the job is still not complete in 10.2A ... but moving along nicely. One of the results of this strictness can seem to be a certain contrast between what is supported in an OO construct versus what is supported in the older non-OO constructs, e.g., no shared variables. What I am referring to here is not those places where the OO implementation is incomplete, of which there are some, but places where there is no intention for the OO construct to ever go there because it is bad OO. Frankly, I aplaud them for this.

It seems to me that we have gotten a pretty good idea of your use case here and it is clear that:

1) There are ways of handling your problem through techniques such as an object manager, similar to Tim Kuehn's Procedure Manger (http://www.oehive.org/project/proc-manager) such that an identifier can be passed back to the client and then used to identify the class on a return call. In fact, this approach is far superior to passing back a handle since the handle is session-specific while the identifier is not so the manager approach could be used in a state-free context as well as your current stateful context.

2) There are several aspects about your current architecture which do not conform to what is currently believed to be good practice, e.g., the stateful AppServers. You would get a far greater ROI on modernizing your application by focusing on remedying that architecture than by focusing on OO. That doesn't mean that OO couldn't help you in that modernization ... quite the contrary, it is likely to be a key resource. What it means is that torturing OO to fit into your current architecture will not help modernize it, but rather will add new tortures to what is already there.

What you really need is a good review of your current status, a plan for where you would like to go, and a strategy for how to get there. Apply that to your priority tasks as they arise and you can gradually evolve to a better architecture. Without it, you are only piling the spaghetti into a deeper mound.

Sorry to lecture, but this is what I do for a living ...