Classes and super-procedures: Bug or feature?

I'm inclined to agree.  What good is compile time type checking when you can add an arbitrary SP to the namespace?

My tendency is, this needs to be a bug - and shouldn't be touched by anyone! Anybody from PSC with an opinion or statement?

I'd report this to tech-support as a bug (my unofficial opinion )

-- peter

I'd report this to tech-support as a bug (my unofficial opinion )

So that I'm the one to blame

Just tell them "Peter says its a bug (unofficially)".

I'd say if one can do

RUN x IN hdl.

from an object, then adding SP API's to an objects search space makes logical sense, particularly for shops which have lots of SP-based code out there want to get at that functionality in the OO world.

So you'd blame me when that would be fixed as a bug.

then adding SP's to an objects search space makes logical sense

But in that case, oObjectInstance:ADD-SUPER-PROCEDURE should be a valid method of Progress.Lang.Object - but it is not. You need to use the trick of abusing the (probable malicious) SOURCE-PROCEDURE reference in a .p called by the object. Hence the suspicion of a bug.

(Session supers work fine and that sounsd reasonable to me).

Anyone from Progress with an official statement? Would be required for folks like Tim that might want to rely on this behavior (to not use the term feature).

I just found out that this allows me to DYNAMIC-FUNCTION into property getters and setters (only when they have an implementation). Smells a whole lot like ADM2 now

While Tim has a point about compatability with existing code, there are clearly limits to how much compatability is really desireable, e.g. shared variables.

One of the things that would concern me is that this smells like it is a side-effect of the OO implementation borrowing on existing superprocedure implementation.  We have seen recently with the instance static versus class static issue that such shortcuts are not always desireable.  One suspects, in particular, that such borrowing is responsible for the current implementation that provides the performance penalty for inheritance.  I would certainly not want to enshrine questionable syntax that would prevent them from changing the way this implementation was done in order to improve the performance.

While Tim has a point about compatability with existing code, there are clearly limits to how much compatability is really desireable, e.g. shared variables.

IMHO, the proper way for using (non session) super-procedures with classes is to use a general purpose empty .p, load it persistently from the class, destroy it in the constructor, register the super-procedure against that empty .p file and run the super-procedures internal procedures IN that empty .p file. In that case even TARGET-PROCEDURE points to a valid object (excuse my 10 years of ADM2, it needs to be a valid persistent procedure). When the actual .p needs to call into the class, it needs a reference to "it's" class or interface type. You can't call back into the class using a RUN xyz IN TAREGT-PROCEDURE.

There are logical consequences of the different programming paradigms.

Compatibility is reached by being able to use classes from procedures and procedures from classes, not necessarily using the identical syntax. Usually wrappers are your best friend (even for weird SHARED/GLOBAL SHARED Variable constructs).

Nachricht geändert durch Mike Fechner

I'd report this to tech-support as a bug (my unofficial opinion  )

W007200146

tamhas schrieb:
Just tell them "Peter says its a bug (unofficially)". 

Done.

I agree.  While there are times that one has to bridge paradigms, there are patterns for doing so which make the bridge apparent and clean so that as one continues to refactor the application one isn't having to clean up garbage left over from the mixed mode implementation.

I agree.

I guess I should get that printed and framed.

I Agree!

Let's make it a bit more worth printing!

Mike,

But in that case, oObjectInstance:ADD-SUPER-PROCEDURE should be a valid method of Progress.Lang.Object - but it is not. You need to use the trick of abusing the (probable malicious) SOURCE-PROCEDURE reference in a .p called by the object. Hence the suspicion of a bug.

I'm curious as to how you found this, and also if you using SOURCE-PROCEDURE in production (as it were)? And if so, why? (to be blunt ) I guess I never really understood the reasons for using SOURCE-PROCEDURE, even in (super) procedural code.

(Session supers work fine and that sounsd reasonable to me).

Absolutely. I would agree, but that's been taken in this thread.

-- peter

I'm curious as to how you found this, and also if you using SOURCE-PROCEDURE in production (as it were)?

It wasn't me. It was a customer that had issues with his OO code and tries to make the OO code work with his procedural (ADM2 + extensions) based code.

As you know we are helping Progress developers to move towards OOABL and GUI for .NET. I fell across this when helping to debug another issue. They've had a mechanism of using SOURCE-PROCEDURE in a persistent procedure manager for loading SUPER-PROCEDUREs to the SOURCE-PROCEDURE (I would have rather passed the procedure handle, than to rely on SOURCE-PROCEDURE, ...). For them it seemed a natural process to move on with that and try to use it with classes. And apparently it works. So it's probably more something that people may run across when getting started with OOABL.

I told them they should be careful until we have confirmation if it's a bug or intended functionality and that my feeling is strongly towards the bug or at least an unintended functionality.

I guess I never really understood the reasons for using SOURCE-PROCEDURE, even in (super) procedural code.

Same here. I never really used it. And I never really missed something like an SOURCE-OBJECT reference in OO code. SOURCE-PROCEDURE is almost as useless like the DYNAMIC-CAST, but that's another story.

5 answer points for that...

(Now I've got 2 answer points left in this thread for an official opinion from Progress).

Same here. I never really used it. And I never really missed something like

an SOURCE-OBJECT reference in OO code.

Indeed - and if we (as developers) follow the .NET model of passing 'sender' for events, it's truly a non-issue.

(I would have rather passed the procedure handle, than to rely on SOURCE-PROCEDURE, ...).

Given that this is at the very least "unintended functionality" (I like that phrase), can you not persuade them to use a more robust model of passing the procedure handle/object reference as an explicit argument?

-- peter

Given that this is at the very least "unintended functionality" (I like that phrase), can you not persuade them to use a more robust model of passing the procedure handle/object reference as an explicit argument?

Already done.

As described in one of the previous posts here they are using a decicated persistent procedure, managed by the object and register the super-procedures against that persistent procedure.

Thanks for the clarification, Evan!

pjudge wrote:
I'm curious as to how you found this, and also if you using SOURCE-PROCEDURE in production (as it were)? And if so, why? (to be blunt  ) I guess I never really understood the reasons for using SOURCE-PROCEDURE, even in (super) procedural code.

I've used source-procedure in combination with an IP name passed to a PP to do callbacks. I've also used it cases where a called .p needed to call an IP in the calling .p (yes, it was strange, however the alternatives were worse.)

bleicher wrote:
As already noted several times in this thread adding super procedures to the SESSION handle is an appropriate and valid design.

It also carries with it a performance hit and lack of scope control for the APIs.

I'd submit that Mike's "add the SP's to a PP and RUN x IN pp-hdl" alternative is better.

Tim