> On Sat, Apr 22, 2017 at 8:33 PM, JPR via 4D_Tech <4d_tech@lists.4d.com> wrote: > Hi David, > > What I mean is just that I feel nothing obvious when manipulating Objects. > Every single operation you can do on objects becomes not trivial at all, if > you compare with variables 4D Developers are accustomed to use.
Very good point! That's all quite true, and training would certainly be helpful for people that haven't had the time to dig into the details yet. > And you can continue as far as you want. It's the same for just using an > object. In the case I use in CustomObjectField, I'm just giving end user an > access to an object field in order for him to add whatever he wants to the > Products table (for instance). In fact, I just don't care about theory on > climbing a tree up and down, I just want my user to add it's own stuff to the > records. And the component does the job. User adds data, and is able to query > on it, and i takes 5 minutes to install. Yes, I've come to see that you guys in France are enamored of object fields and a great many of the decisions about JSON and C_OBJECT flow from that. I watched some excellent Summit presentations and have a clearer idea about the mindset. I will note however that it took me roughly two minutes to optimize the 4D Summit database that show relations as 'slow' so that the relations too 40% of the original time to complete. I also noted that the presentation made no comment on how hard it would be to use the data to answer any question that you hadn't designed the object structure to address *in advance*. Since the object fields are an interface onto underlying has tables, that makes sense. There's no such thing as a reverse hash table. So the love of object fields in France is something that I can understand a bit, but it doesn't help me at all. I have occasional situations where object fields could prove very useful...but not many. In a complex system with hundreds of tables, I might have a couple that had a special requirement where I think that object fields are either a) an acceptable shortcut or b) offer special features that I need for specific searches. I have zero antipathy to the relational model and am not in love with stuffing things into blobs/objects/whatever. Subtables were a terrible feature (I used them once) and object fields face many of the same hazards. Object fields, like subfields before them, offer some interesting properties as novel index/search structures. But for general use? Not so much. For dynamic databases? I can imagine a few big 4D OEMs that need that but for anyone else? It's a bit of a trap. For people outside of the 4D world? Not an attraction - they just use standard SQL commands to build their tables and never look back. No need for any sort of embedded system with hard-to-write queries. But this is all a very long discussion. I mention a tree-oriented approach to JSON because that's the fundamental nature of JSON in the rest of the universe. I don't know JSON from 4D, I know JSON from elsewhere. As you and others in France may have observed, many of us are befuddled as to why 4D doesn't have complete support for *arbitrary* JSON. It makes it pointlessly difficult to interact with other environments and services. That's a shame because 4D is a *fantastic* environment (for those of us that know it) to serve as a hub. It's great for pulling and pushing data in all sorts of formats and in all sorts of ways. It's one of it's greatest strengths. But you need to support any sort of JSON for that in this modern world. > > It's a pity, because JSON is really easy. Normally. > Sorry, but I don't think JSON is easy for everybody on this planet. My mother, > at least, has some problems entering data without mistakes ;-) Who enters data in JSON? If your mother programs in anything other than 4D (which I expect you would fight about!), then she would have none of the problems I (and others) despair of. I have to say this is a pretty weird point to defend 4D on. JSON is an interchange format. 4D doesn't support it as an interchange format. Instead, it uses JSON notation for some internal purposes. Those of us that interact with the outside world want a complete implementation. The easy and correct answer is "yeah, 4D needs this. We know that and will do it." There are plenty of cases where 4D features are a matter of taste and preference. I'll admit that you could fairly say that some of my preferences are a minority opinion and that it's pretty reasonable to ignore them. I'm fine with that. In this case, 4D dropped the ball. Not that there's a huge amount wrong with the internal use of JSON (although the typing problem is a real pain). But as a JSON module? It's not really something that can sensibly defended. Why not just hire Rob to add the feature? Why not just compile in one of the available libraries, much as Rob does. > > The basic problem is that 4D is lacking basic features: > Sorry again, David, but you forgot one word: > "4D is lacking basic features YET" Well, I decided about 20 years ago not to make any plans based on software that wasn't shipping. I've never regretted that. In this case, 4D introduced C_OBJECT and some JSON support in, I believe, V14. (I never really used V14 or V15.) Now we're onto V16 and the features are still missing. How soon is "YET"? Who knows. The SQL engine seems to have been abandoned. I'll stick with features that I can use today, everything else is imaginary until it arrives. Full JSON support is a *fundamental requirement* for a programming language today. 4D does itself no favors by 1) not having it and 2) trying to pretend that it's not a problem. It's quite amazing that this even has to be discussed. That, for sure, I do not understand. I've got NTK so I'm okay, but it shouldn't require an expensive plug-in. (I love NTK and would find an excuse to buy it anyway, but still.) > Now, let's suppose that the way Objects are used in 4D today is not perfect. I > agree. But we may reasonably think that it may be improved in the futures, may > not we? It let us with 2 solutions: 3: Use another tool. That might be 4D+NTK, it might be something else entirely that deals with JSON natively. I hope that we all agree that we want 4D to be as good as it can possibly be. So I hope that everyone takes my comments in the spirt that they are delivered. I guess that I'd call it a sort of frustrated optimism. I think 4D's great, I just want it to be better...adding JSON and a few other basic features really seem like low-hanging fruit. My feature requests over on the forums have largely focused on exactly such sorts of features. Little, not so complex things that would make a big difference to all of us developers. Nothing big and complicated, nothing multi-part and involved. Just basic, rudimentary language features and structures. JPR, thanks for writing back. As much as I sound...however it is I sound...I am grateful to you for commenting. We don't hear enough here directly from people that work for or at 4D in France. So, a big thank you. Also, I tend to make a strong argument, but don't take it the wrong way! Also, I'm fine that people don't agree with me. I'm happy when people articulate a different point of view. When I'm lucky, I change my mind because I see something I hadn't. Also, sometimes programmers come to different conclusions for entirely good reasons. So, even if we don't agree, no one has to be 'wrong.' Programming is a creative enterprise, not a zero-sum game. I'm a huge 4D fan, have been for decades. It just pains me that it isn't grabbing easy opportunities to make it better. Thanks for listening. P.S. I know for individual emails and calls with a wide variety of developers that my opinions are neither universally shared nor anything close to rare. I'd be keen to hear from others that they think is important and unimportant. People that agree/disagree/think about something else entirely are all welcome. P.P.S. Yeah, I've been on the list a lot lately after very little activity for several years. I'll calm down ;-) I ignored V14 and V15 (although I had them) and stuck with V13. Now I'm in V16 and have some catching up to do. GRAPH next! So far, I like it. In this case, I don't have any investment in what it replaced, so I'm ready to accept it as it is. So far, I like it fine. ********************************************************************** 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
