naming conventions

Author: i2stiller@gmx.de (istiller)

So, now I'll start a survey Laugh Is out there any preferred naming conventions of operations? As in other languages I named an operation which does some display "DISPLAY" and another one printing will named "PRINT". So an activate looks like: activate v_INST."DISPLAY"(...) or v_handle->"DISPLAY"(...) But the disadvantage is, that UnifAce editor highlights this like any other "display" statmenent. So I thought about OP_DISPLAY, OP_PRINT, OP_xyz, ... And as will all know, one drawback of UnifAce is, there is no overloading of functions. Say, there is the need for two PRINT-Operations OP_PRINT(a_parameter_typ1) and OP_PRINT(a_parameter_typ2) Okay, the only solution so far in UnifAce is two write two Operations OP_PRINT1 and OP_PRINT2   So the survey is:

  1.   how do you name operations in general?
  2.   how do you name such overloaded functions?

Any hint / comment is appreciated Smile Ingo

11 Comments

  1. istiller said Hi Zdeněk, hi Gianni ... BUT But what about handles and structures? One can't pass handle and structs as part of a UIL, as UnifAce do not proper convert between string and handl/struct. ...

    Hello Ingo, we don't use handles. :-) We have tried, but there are too many problems with them. So we keep using named instances, which is string and it's very easy to pass them as parameter. I don't see any benefit in handles over named-instances. All in all its always just "handle" to a component instance and since our application is quite "old", it's impossible to change everything to handle... and it's much easier to have only one approach. And as for structures... well... we don't use structs. :D We use them maybe in 2 components? Since it's quite easy (and the only way) to convert data from Uniface to json for example. But internally, we use lists and id-lists. The situation is quite similar to handles. Don't see much benefits. As long as structs has limited usage (for example it can't be passed to a 3GL component), there is no reason to use them. So, all in all... our "handles" are strings and "structs" are in fact idlists, so strings, too - we have no problem passing this as parameter to anything (be it Uniface component or 3GL or Oracle SQL or PL/SQL or anything). Kind regards, Zdeněk Socha


    Author: sochaz (zdenek.socha@fullsys.cz)
  2. Hi Ingo, what about: X_OPNAME[_SPECIFIC] X = prefix helping developer to immediately identify the origin of the operation like: T for Templates, G for Globals (Includes, Model, ...) and C for Component OPNAME = what the operation is globally doing SPECIFIC = (optional) like in your example the two different PRINT operation will be specific to different specific needs Hope it helps... Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  3. Hi,   just quick answers: 1. in 95% we do not use English to name the operations/entries/global procedures etc... :-) 2. we solved this problem by starting to use id-lists as parameters... hopefully the consequences are obvious here...  Ok... here is an example: for standard operation in a service component, there are always 5 parameters defined as string: data in, parameters in, data out, parameters out, message out. The first 4 parameters are always idlist (which may contain sublists of course). The last parameter is reserved for error message, just a simple human-readable... oh... end-user readable string. In your example, there would be only one operation OP_PRINT and you can send a different data. Or you can send exactly the same data, but in the "parameters in" parameter you would send the type of operation, or type of data or whatever you need to influence the behavior of that operation. Of course, should you need a new behavior, there is no change in the signature (this was really very very very appreciated in the times we were using those .dol and .urr files). Regards, Zdeněk Socha


    Author: sochaz (zdenek.socha@fullsys.cz)
  4. gianni said Hi Ingo, what about: X_OPNAME[_SPECIFIC] X = prefix helping developer to immediately identify the origin of the operation like: T for Templates, G for Globals (Includes, Model, ...) and C for Component OPNAME = what the operation is globally doing SPECIFIC = (optional) like in your example the two different PRINT operation will be specific to different specific needs Hope it helps... Gianni

    I forgot something! Sorry... All operations use uniface lists as params...something similar to sochaz: MY_OPERATION_NAME(params_in, params_out, controls_inout); params_in are input params, params_out are output params while controls_inout are environment variables needed to correctly execute MY_OPERATION_NAME without using external references. Now it's all... Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  5. Hi Zdeněk, hi Gianni Thanks for your answers. And we did it the same way, we do have four "string" parameters

    1. VAL_IN     ;  UIL input   (UIL=UnifaceItemList, maybe nested)
    2. VAL_OUT  ;  UIL ouput
    3. PARA        ;  UIL control parameter
    4. GDA         ;  UIL for global data (like session infos, last errors, ...)

    To this point, we don't have to change an signature even if we change the structure of the input BUT But what about handles and structures? One can't pass handle and structs as part of a UIL, as UnifAce do not proper convert between string and handl/struct. The first handle to exchange with another component and you can forget about strings/UIL Frown So there is a need for special operations with parameter of type handle resp. struc Ingo BTW: I could not get UnifAce to return a collection handle via operation parameter (between two components) If we use globale variables of type handle, that's no problem. Any one experienced the same problem?


    Author: istiller (i2stiller@gmx.de)
  6. istiller said BUT But what about handles and structures? One can't pass handle and structs as part of a UIL, as UnifAce do not proper convert between string and handl/struct. The first handle to exchange with another component and you can forget about strings/UIL Frown So there is a need for special operations with parameter of type handle resp. struc

     Instead of a UIL (Uniface List) you could use Struct parameters. A Struct can handle (AFAIK) all the available Uniface data types. One catch: I believe handles can only be "stored" in Structs since Uniface 9.7.01.

    BTW: I could not get UnifAce to return a collection handle via operation parameter (between two components) If we use globale variables of type handle, that's no problem. Any one experienced the same problem?

     I currently have no (good) explanation for this. I would need to do some tests. But did you define the Collection Operation(s) on Model level or just in the component? AFAIK the collection and occurrence operation(s) are not automatically added to the component signatures (for details see here and here). Maybe this could be a possible explanation for the behavior you're seeing. Just an idea. Hope this helps. Daniel Uniface Support


    Author: diseli (daniel.iseli@uniface.com)
  7. And I got another "conflict" when try to name things Laugh I'm currently building a framework for handling SOAP-request. There are several services dealing with entities, on each entity there are collection occurences operations. So far so good ... As Uniface could name globale procedures only by 16 characters, I have to shorten some of of this name. But then I run into a conflict for the abbreviation for "collection".

    long name short name remark
    occurence OCC this one is easy
    collection COL I want to have all the same length as 3
    column COL If I need sometime a column: *grrrrrrrrrrrrrrrrrrrrrr*

    Any idea for naming this "things" Wink TIA Ingo


    Author: istiller (i2stiller@gmx.de)
  8. Hi Ingo, As a quick thinking I prefer COL for COLUMN...so what about CLL for collection ? As a separate thinking I was faithful to 3 letters shortnames for long time...since few years I moved to 4... :-) Cheers from Italy...Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  9. gianni said Hi Ingo, As a quick thinking I prefer COL for COLUMN...so what about CLL for collection ? As a separate thinking I was faithful to 3 letters shortnames for long time...since few years I moved to 4... :-) Cheers from Italy...Gianni  

    ThanX Gianni I will use CLL Kiss Greetings from good old germany Ingo


    Author: istiller (i2stiller@gmx.de)
  10. Suggestion CLM for column CLC for collection Trying to make things unique, based on consonants


    Author: Arjen van Vliet (arjen.van.vliet@uniface.com)
  11. Arjens suggestions brings back the "cnsnnts nl(y) wndrfl" good old unix times. But as in unix: for a non-insider, it's far from intuitive As I think it's hard to beat the LIN/COL heritage, so we have to find a 3-letter-word for collection: Right now in the data model, uniface suggests the postfix "COLL" for interface name, but it competes with "OCC" postfixing the occurence interface name: so what about "OCC" and "LOC" (or "AOC" from "All Occurences")


    Author: ulrich-merkel (ulrichmerkel@web.de)