On Thu, Sep 15, 2016 at 11:11 AM, John DeSoi <[email protected]> wrote:
> I could possibly agree with this if objects were more powerful and complete, > but in the current implementation it just invites mistakes and maintenance > issues. Object property names are just strings. Unless you build your own > system where every property is an object that can provide meta-data, you can't > even determine the type of the property. 4D objects are not self-describing as > in other object systems. Having variables (and parameters) allows type > checking and cross referencing to understand where things are used in the code > base. If I have 100 instances of "name" as a property in my code, there is no > way to safely make a change to that if I only want it to impact a subset of my > objects. All fair criticisms and observations. For sure, 4D's lack of understanding of types past the built-in simples is a long-standing frustration. C_OBJECT is kind of misleading -they're not structs/records/objects... they're more like C_STRUCTURED_TEXT, as you point out. For anyone planning to use CALL WORKER solely as designed, then the direct parameter passing looks great. This is what Thomas demonstrated and it makes for some very simple+powerful+readable code. Alternatively, the just-one-JSON-block probably adds complexity with no benefit to most examples, in this case. But you have to pick your fights in 4D (or anything else)...If you think that you'll want to move to a larger system with custom features, you'll need records or documents and, at that point, the direct primitive parameters are likely to be a pain. They don't translate outside of 4D and don't map easily to anything _in_ 4D, apart from a big BLOB. In case it's not clear, I've been down this particular road before...I was going with specific fields....a big BLOB was ultimately easier to work with.JSON is the new BLOB ;-) Anyway with just one data container, your transport and data storage code can be written once and then forgotten about. For what it's worth, the task queues that I've written or been involved with in the past didn't have a huge number of different message types. So, it wasn't a matter of hundreds of different messages - more like a dozen or two. At that point, the code for composing and then parsing a message isn't that hard to verify. For every composition (sender) you've got a reader (receiver.) They need to be kept in sync. Not entirely generic, but error-free once you're done. (Entirely generic is overrated, IMO...and I've been guiltier than many of going too far in that direction.) Put another way, once the message format is stable and the code to build/consume the message is verified, you're done. Nothing needs to change in that area again. Message formats *should* end up being very stable over time or else something else is going wrong in the system and/or it's early days and your'e still in discovery mode. Oh, reminder: Put version numbers in messages as part of your standard format so that you know if you're getting an obsolete format, want to switch up your parser code to support multiple versions, etc. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
