aOn 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. I was just thinking about John's post again and think it's worth more comment. John's points are all right. If you look at Thomas' presentation, you'll see how clear and readable calls to CALL WORKER on when you pass parameters. In contrast, passing through a JSON block or reference of some kind is completely opaque. You can't see what's going on from the call, you have to figure out what's going into the JSON. This is potentially a quick road to hard to debug, hard to trace, sloppy code. I truly detest the habit in JavaScript to pass around these ginormous JSON manifests. Ugh. (Particularly in JavaScript where closures are super nice...we just don't have anything like them in 4D.) Anyway, I can clearly complain about anything ;-) I've been recommending a JSON-messaging strategy for a *minority* of cases. Namely, the situations where CALL WORKER is going to be extended to a multi-machine setup of any kind. Say, for example, that you want to pass message to a compiled-and-merged app. That's a sweet setup. You can get very stable little 'clients' using pure 4D code. In fact, you can set up build parameters so that you main system and the compiled-and-merged versions come out of the same code base. In that situation, you'll be happy to have JSON blocks. But how often is this going to be the case? I don't know. I'd guess the minority - maybe never for some people. (For me it's 'always' because I'm used to distributed processing and that's how I think about it...but that's me.) Is it worth overbuilding something for a minority case you might not have? Usually not. Sometimes it is and then it's a bit+ painful to do a rewrite...but what about the times you overwrite Just In Case and never need the extra features? I always feel foolish for having wasted the time and effort to make a *more* complex system for zero gain. So potentially, a painful rewrite or potentially hanging your head in shame over pointlessly complex code. Like so many things, judgement call. So: * If you're only ever going to use CALL WORKER on one machine, as designed, use raw parameters. This makes for much better and more readable 4D code that a new programmer can pick up right away. * If you're going to extend or replace CALL WORKER _for sure_, I'd suggest starting with JSON blocks and working out some generalized tools for naming/documentation/parsing/building/validating along the way. * If you _might_ extend or replace CALL WORKER, it's a tougher call. Go with your gut. In any case, you could always write a CALL WORKER adapter where your normal CALL WORKER handlers write reformatted messages as JSON blocks for your extended system. File under "it depends." Judgement calls. That's why we get the medium bucks. ********************************************************************** 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] **********************************************************************
