Why are constants less useful? If the value is equal to the constant, it avoids potential upper/lower case problems, no?
On Wed, Oct 3, 2018 at 5:41 PM Kirk Brooks via 4D_Tech <[email protected]> wrote: > Paul, > You touch on an excellent point about using objects. At the heart of it is > your naming convention. We haven't had to worry about naming too much in > the past. Variable names aren't case sensitive and you could always use the > COMPILER_ methods to document the IP and process variables. And the same is > true for the object variables themselves. > > When it comes to the properties (or keys as in key:value) it's a different > story. Starting with them being case sensitive. I find a difference in how > I handle this between being able to handle native dot notation and not. The > difference being in v15 I used constants for (not IP vars) key names. You > can still do this in v17 but it's less useful. Looking through some > projects here are the main schemes I use for documenting how an object is > structured. > > 1) a disk file > Add a folder to Resources and keep templates for various objects there. Or > a single file with templates listed as objects. I do this for large > templates, for objects with lots of default data, for objects I want to be > able to configure for specific instances and for objects defined by some > other service I communicate with. Reading them is fast. Fast enough to use > when loading a form, for example, though obviously I wouldn't do this > inside a loop. > > Working with large objects benefits by being able to open them in my text > editor. A line like: > > $account_id:=$obj.source.data[2].customer.preferences.account.number > > is easier for me when I can be looking at the object. Especially if it's > from some other source (like a API call). > > 2) in the method header > Perfect for defining keys as parameters. > > // MyMethod (object) > > // $1: { date: , person_id: , query_str: } > > Handy because it pops up in the method editor to remind me what the keys > are. > > I also do this to document moderate sized objects returned by a method. > > 3) initialization or getter methods > > $obj:=Address_get_object > > where the method initializes the object. This could include reading a disk > file or simply defining the object in code. Frequently I write these to > include an optional param for the key value of a record so it either > returns an empty object or a specific record. With a complementary SAVE > method it's a good way to manage record data. > > 4) readMe files for each module > Module? Addresses for example. I'd make a folder in Home named ADDRESS and > a method named Address_readMe. This method is where I make notes about > what's important and explain what is supposed to be going on. Like naming > conventions for addresses and the structure of objects. > > Like I said at the start a good naming convention is your friend. > Especially in v17. Decide for yourself how you are going to manage key > names. Basically this comes down to camelCase or snake_case. The first > character of the name must be a letter, underscore or $. Decide what $ and > _ mean and be consistent. Avoid "stringly_typing" : using the key to imply > metadata like type, usage etc. These things are totally mutable in an > object. It can seem like a good idea in the short term but will bite you > eventually. > > And don't forget you have JSON Validate. Validation schemas can be quite > complex but they don't have to be. Again, you can include a validation > document(s) in the Resources folder to check critical objects against > before using. > > I encourage you to just begin working with them. When you find yourself > getting bogged down take a step back because you are likely trying to use > these new tools incorrectly. This is the hardest thing for long time 4D > devs - things we've done a certain way for years can be done with the new > tools a different, easier way. > > Objects and collections are the gateway drug to ORDA and your programming > life will never be the same again. > > Hope this helps. > > On Wed, Oct 3, 2018 at 6:02 AM Paul Dennis via 4D_Tech < > [email protected]> > wrote: > > > We have not started using objects in our application but I can see how > they > > could be useful. However where I am struggling is how we are supposed to > > keep documentation as to the object definition. With database structure > you > > can clearly see the definition of the table and fields and these are > > available in the method editor for lookup. > > > > Am I missing something as it seems to me that it would be very easy to > get > > in a mess as to definition and contents of an object. Would appreciate > > feedback as to have everyone is managing this. We are using V16 R6. > > Thanks > > Paul > > > > > > > > -- > > Sent from: http://4d.1045681.n5.nabble.com/4D-Tech-f1376241.html > > ********************************************************************** > > 4D Internet Users Group (4D iNUG) > > Archive: http://lists.4d.com/archives.html > > Options: https://lists.4d.com/mailman/options/4d_tech > > Unsub: mailto:[email protected] > > ********************************************************************** > > > > -- > Kirk Brooks > San Francisco, CA > ======================= > > *We go vote - they go home* > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** -- Jim Dorrance [email protected] [email protected] www.4d.dorrance.eu PS: If you know of anyone that needs an experienced 4D programmer to add energy and experience to their team, please let me know. I have experience in many areas. Reasonable rates. Remote or Paris only. ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
