Why not instead of CALL SomeProg('GetCustomerBalance',...) and CALL
SomeProg('PaintScreen',...)
do:
CALL GetCustomerBalance
Call PaintScreenAnother rule of structural programming - every program can have only one purpose :). Unfortunately in case of U2 sometimes we have to live with the programming language limitations. One of those limitation - no OOP. This is the only reason one should choose to do something of the kind you have described - the reason to mimic some of the elements of OOP (this is also why one might to use COMMONs as well - this is the only reason for COMMON, emulating elements of OOP, not passing parameters around). But in that case it is wrong to make the first parameter a name of the subroutine to jump to. If should be just a meaningful value. Inside the program the value is checked (probably in a CASE statement) and a decision is made on what exactly should happen. The calling program should have no knowledge of or directly reference anything what is inside the program. ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, February 14, 2006 12:18 AM Subject: RE: [U2] [UV] GOSUB variable-name? > The purpose of this type of indirection is (or should be) both business and > application related. It's a methodology which helps cohesion (understanding > the problem). I don't see why you should have separate methods for the > business logic from the programming mumbo jumbo. > > > > For example if you pass into a program a description of something you want > it to do, CALL SomeProg('GetCustomerBalance',...) that is business related. > Now if by CALL SomeProg('PaintScreen',...), that is programming mumbo > jumbo, either way, whatever happens within the scope of that call 'is' a > black box. > > > > By using descriptive method arguments it creates cohesion, where you can > pretty much understand 'what' a component does but don't have to know 'how' > it does it (as long as it's working) without having to take the lid off it. > > > > The conversation here has just been a debate on whether a program > could/should branch to a label with the same name by compiler or by > construction. Then if by construction, how do you do it. I don't think > there's any real disagreement in the wider computing world about the > soundness of the methodology, viz object methods. Generally this type of > interface is called "dynamic dispatch" and it's a widely used and respected > method. > > Stuart > > > > ________________________________________ > > > It is always wrong to specify directly in a calling program which branch > the > > > execution should take in a program that is called. It does not matter > > > whether it is using GOSUB @variable or CASE statement. It is also wrong > to > > > pass into the called program the information from where it is been > called. \ > > > Each parameter passed inside a program should have a business-related > > > meaning, not programming jumbo-mumbo. > > > > > > > ********************************************************************** > > This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (+61 3 9269 7555) immediately, who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer related viruses. > > ********************************************************************** > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
