On Wed, Nov 1, 2017 at 1:32 PM, Keisuke Miyako via 4D_Tech < [email protected]> wrote:
> I hate to repeat myself, > > but it seems the problem with object notation > is that it's not as straightforward to know if a field has been changed or not. > but that's not how references work. I almost said earlier "it would be like saying that when you use pointers, you have to know and remember to do an explicit save." > there is literally no way of knowing that an object is a field, just by parsing the code. Could be. But why should I know or care? 4D has made it *very* clear that we are not supposed to know about its internals (or even ask), nor are we to count on them remaining stable between versions. Fine, but that position cuts both ways: You can't then use internals as an excuse. Problems with internals aren't an excuse. They're 4D's problem, so 4D should fix the problem. (We obviously can't.) It's not good enough for Engineering to throw up their hands and say it's going in the too hard basket because of the internals. Since we're not supposed to know about the, telling us about them as an excuse for a bug isn't okay. Particularly when the bug *guarantees* that 4D users and customers will screw up their data. It *will* happen. Imagine this thought exercise: * Ask 100 people "What should happen when you change a field and save the record." 100 people will say "It saves the change." * Ask 100 people "What happens when you change a field and save the record." 100 people will say "It saves the change." No one will say "It depends!" Or "Well, the first thing you have to understand is..." It's 4D's bug, 4D needs to fix it, not expect us to remember this obscure and counter-intuitive "behavior." It's a bug, however it is documented. It's just dead wrong. Hey! I found a 100% reliable workaround: Don't use object fields. ********************************************************************** 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] **********************************************************************
