Tim, On Wed, Nov 1, 2017 at 10:13 AM, Tim Nevels via 4D_Tech < [email protected]> wrote:
> On Nov 1, 2017, at 11:04 AM, Keisuke Miyako wrote: > > > like a global preference, to the effect of > > > > "Call OB Copy implicitly when performing object assignments" > > > > it is an interesting point of view, > > to frame it as an issue of the assignment operator being different, > > as opposed to how objects and their properties are different "because > they are references". > I agree with you it would be great to have a specific operator. To me that would be :== to mean OB COPY instead of OB ASSIGN REF (or whatever what happens now should be called). That way there would be no ambiguity about you want which is important for shared code or components. No idea how practical that is since it would only be valid with a particular data type. I would love to see == added as a type specific comparator too but that's another thread. > > I like that idea. If you are an “expert” or an optimization fanatic > working to reduce every millisecond and every byte of memory used, you turn > the preference OFF. Everything works like it currently does. You know what > your are doing and if you make a mistake, it’s on you. > Thinking about this - let's say I have a situation where I regularly need to use APPLY TO SELECTION to all or a large number of records (large = 100ks or a million) and these might be records in a 'mature' structure so they may have lots and lots of fields including some object fields and maybe even some blobs and big text fields (all stored in the record for sake of argument). The time to run this command will depend on how many records actually have to be written to disk. If the ATS is something like a method that marks records as "done" if some criteria is met most, maybe all, records might not be changed. This wouldn't be an optimization of milliseconds if each record was re-written even if it didn't change. Just speculating but this is could explain why 4D does what it does. Of course if a method is applied that updates the 'done' key in an object field... it's good we know to also make some field level mod to trigger the save action. OTOH - if I have a database where such situations would never occur (though I hate to assume 'never') and I use object fields a lot (and I do) having the option to tell 4D to always rewrite a record on save would be useful. This doesn't bother me really. Sometimes I use 4D to build a race car and sometimes I use it to build a tractor. The cool thing is I can use it to build both. The complication is I can use it to build both. It's up to me not to put 4' tall tires on the race car and not to put the high speed transmission in the tractor even though I can. My perspective - this is a quirk of 4D resulting from mashing up JSON, about as loosey goosey a data transfer protocol as you can get (well, there's REN), with a strictly typed language. It works but there are issues. This is an issue. Which means it needs to be known and documented. I don't want to beat up on the folks maintaining the docs so I agree with the earlier comment about the value of user (developer) comments on the docs for calling out such things. -- Kirk Brooks San Francisco, CA ======================= *The only thing necessary for the triumph of evil is for good men to do nothing.* *- Edmund Burke* ********************************************************************** 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] **********************************************************************
