> On Thu, Jan 12, 2017 at 12:04 AM, JPR <[email protected]> wrote: > [JPR]
Thanks for confirming what I'd feared, that there are missing features and that they've been missing for several years. It's heartening to hear that new and powerful features are on their way. That's great! 4D has been evolving in recent versions in some genuinely excellent ways. I decided some years back to base no business or programming decisions on features that do not yet exist in a stable, shipping product. It's nice to hear about such features, but I can't plan on them or count on them. So, for all practical purposes, they do not exist. (And, obviously, that is the actual case.) > As far as I can find, the internals aren't described anywhere. > You're right, internals aren't described, and will not be, for we need to keep > room for evolution, so internal will change as they are already changing very > often. As soon as we publish a description of the internal handling, Devs > begin to use it and to complain at every new change... While it may be true from time to time that developers complain about a change based on internals, I don't think it's either that common or any reason for major concern. Developers complain, it's our job ;-) And we complain a LOT more about other problems. So not telling us how thing work now because we might complain later isn't a particularly nice argument. I've heard this argument for as long as I've been around 4D. On the one hand, at a Summit or seminar, we may be treated to all sorts of details about internals (sometimes with no obvious practical application), but then at another time we're told. No! You cannot be told! It should be one or the other: discuss certain topics or do not discuss certain topics. Using other tools, there's no particular air of mystery surrounding how things work or how they're implemented. This is also one reason why I typically treat 4D as a black box and test it out from scratch when I need to figure something out: * The documentation is often thin, incomplete or completely absent. Subforms and widgets? Where are they documented in detail? I never found it. The whole two-processes on 4D Server business? Where is it documented? I've never found it. And yet these are both considered topics of great value and importance and promoted as such at Summits. Why no docs? (Or at least any that I've ever found.) The answer cannot be that we shouldn't have the information, it's that the documentation is incomplete. * Much of what I've heard about 4D internals down the years has not been true. Well, it may well have been 100% true from a certain point of view, but it wasn't true in a way that could be measured externally in a real app, so it wasn't useful. So why would I want to hear anything about internals? Well, because it is entirely helpful to hear a good technical discussion at the level of patterns, algorithms, or even implementation. You to give you a tiny trick to hang onto (and then suffer from when it breaks), but to give you a better mental map of the system. It makes it a lot easier to build solid designs on top of a clear understanding, leaving out little tricks. LR and Aparajita, for example, are both masters of this sort of explanation. The sort of discussions that make you feel smarter after you were in the room ;-) When I have to select amongst tools, commercial APIs, and frameworks, just about the first thing I do is to try the tool out, work with the docs, and write to tech support with a question. My choice of tools depends more on the docs and how my question is dealt with than the features. (In many situations, multiple tools offer enough features.) It's quite time-consuming and at times exhausting to have to research 4D's behavior on my own. More comprehensive and reliable documentation of various sorts would make 4D a whole lot more appealing. As an example, subforms sound just fantastic...but I couldn't find any docs, didn't get them to work as I could find described and so I gave up. It's just too much work. And without docs, I have really got no idea how future versions might change things. Components, for example, have had radical changes made between versions so I only try them again every couple of big releases. Help me out here people, are there any good docs on subforms? I know a few of you use them, but I've kind of taken them to be a Miyako-only feature ;-) But he's smarter than most everyone else, so that doesn't make me qualified to use them. > > Count Elements > This also, but just from this simple demand, you may understand how complex it > can be. Count what ? Every property ? Every sub-property ? On how many levels > ? Including the arrays' sizes ? The question is : What do you want to count, > and how? Obviously, today, the OB GET PROPERTY NAMES does the job Your answer points to the underlying problem: The JSON isn't being exposed as a tree. I don't expect the object commands to do that, but the JSON commands should. I mean, it's like having to deal with an XML DOM without tree navigation. If you've got tree nodes, then it's entirely clear what to count. (Or at least you can know how to traverse the nodes and count as you like.) > recursivity is fun, isn't it? <pointless_side_rant>I'm not a fan of recursion. It's just a quick-and-dirty way of getting a memory-inefficient processing stack. Years ago I didn't get it, then I did, saw the appeal, and quickly realized it's kind of a lazy approach and broadly over-recommended. I mean, every you're-new-to-programming-let's-do-a-factorial example in history seems to use recursion. Why? It kind of blows your mind the first time you 'get it' and I think that's pretty seductive for many of us, at least for a bit. But it was the quick way of doing it in this case and there's no real chance of a runaway situation.</pointless_side_rant> > I did it for the Component I've made for the 2016 training and the 2017 Tour > (Look into CustomObjectField.4dbase). Just by getting recursively lists of > properties from OB GET PROPERTY NAMES($obj; $arNames; $arTypes) You have it in > the examples I've given during the Sydney's training. Hey! Thanks for the reminder. I just dug it up and the demo looks really great. I love that you've taken the same data structure and offered so many views onto it. Beautiful. The underlying code is pretty dense, but it seems that what you're doing is what you describe in your post: * Cast any array with elements as text and see if the first element is [object Object]. If so, deal with it as an array of objects. * For everything else, treat it as text - no matter what it's original type. Warning: You're depending on the coercion of object arrays to text arrays turning up as [object Object]. I think that this is an undocumented behavior, so 4D may change it in a future version. Then again, you can go and complain to those guys directly ;-) Memo to self: Never count on this behavior if you plan to store the string [object Object] in a text array element. > You are right! Because it IS incomplete! But wait a little bit, and you will > see huge evolutions... I'll be very pleased when that day arrives. As people may have noticed from my crazed posts on CALL FORM and CALL WORKER, I can be a pretty big fan of beautifully done features. > Hope this helps, > My very best, > JPR Thanks for taking the time to answer when you are understandably busy. It's always great to hear from people that work at or with the 4D companies directly. ********************************************************************** 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] **********************************************************************
