It would work for user created objects, except how do you get datagrids to do this? All kinds of things in the datagrid are linked by long ID's to their behaviors by the engine. I'd be nervous about going into any functioning datagrid and trying to update all the object behavior references, and then when the datagrid creates new objects, unless you modify the datagrid library, it is also going to assign long ID's to those.
This does bring up an interesting point though. I think the datagrid library could be updated in such a way that the objects it creates could be persistent, that is, given the same size datagrid, same rows and columns, the objects would not be deleted or recreated simply because the data changed. It would also address the issue of how to deal with adding data below the last data in the datagrid. If the cells were already there you would just double click on one to edit it. It would be quite an undertaking, but it is my opinion that the datagrid should have been designed this way to begin with. It solves a lot of problems we run into now, and we have discussed previously what happens in an app after a number of years of heavy use if you run out of ID's. It's hardly likely I suppose, but it's a possibility. Just thinking out loud here. Bob On Jan 24, 2012, at 1:28 PM, stephen barncard wrote: > uniquely naming all objects and using 'get the id of object <name>' > instead of using any IDs at all would seem to solve this problem... > > of course would have to be a convention when starting a project. > > why wouldn't this work? > > On 24 January 2012 13:20, Bob Sneidar <b...@twft.com> wrote: > >> Yes the more I think about it, the more tedious it becomes. It seems the >> only way to do multiuser dev is to have the source stack available to a >> kind of checkout engine. A dev would have to check out an object at which >> point it would be unavailable to any other user. And you would have to have >> a running copy that was the exact replica of the original including ID's. >> Not sure how to do that. >> >> Way back when some made the argument that it was a bad idea to use ID's as >> references to objects. Now it seems we understand much more how true that >> is. We are beyond the point of know return now. :-) >> >> Bob >> >> >> On Jan 24, 2012, at 11:59 AM, Pete wrote: >> >>> Bob, >>> I think you'd have to find some way to preserve object IDs or a lot of >>> stuff would break. Datagrids, for example, store the row template as a >>> long id. And, as you pointed out, behaviors. >> >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > > > -- > > > > Stephen Barncard > San Francisco Ca. USA > > more about sqb <http://www.google.com/profiles/sbarncar> > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
