One thing that comes to mind are copying garbage collectors which need to keep track of references while moving objects around. Probably looking into how that is solved will provide some insight.
On Sun, Oct 5, 2014 at 12:35 PM, John Carlson <yottz...@gmail.com> wrote: > Not obvious to me. Are you saying a folder of shortcuts? A shortcut to > a folder? A shortcut to a shortcut to a folder? Instead of using > indirect addressing, can you put it in terms of folders and shortcuts, or > do we need a third type of object? And how does this apply to a general > graph problem? Are you speaking of URNs? A directory of hard links? > That seems to make the most sense to me, and would bring in the third type > of object. Can you really make a hard link to a directory, and expect it > to work? I'm not thinking of something with two levels, I am thinking of a > multilevel problem, where the shortcuts go really deep, like from a desktop > to somewhere into program files. If I rename a program files folder, what > happens to my shortcuts? If you like I can put this into Linux/BSD terms > which I am more comfortable with. I am trying to address it to a larger > audience than that though. > > On Sun, Oct 5, 2014 at 8:49 AM, Miles Fidelman <mfidel...@meetinghouse.net > > wrote: > >> Isn't the obvious answer to use indirect addressing via a directory? >> >> John Carlson wrote: >> >>> To put the problem in entirely file system terminology, What happens to >>> a folder with shortcuts into it when you move the folder? How does one >>> automatically repoint the shortcuts? Has this problem been solved in >>> computer science? On linux, the shortcuts would be symbolic links. >>> >>> I had a dream about smallstar when I was thinking about this. The >>> author was essentially asking me how to fix it. He was showing me a >>> hierarchy, then he moved part of the hierarchy into a subfolder and asked >>> me how to automate it--especially the links to the original hierarchy. >>> >>> In language terms, this would be equivalent of refactoring a class which >>> gets dropped down into an inner class. This might be solved. I'm not sure. >>> >>> This would be a great problem to solve on the web as well...does Xanadu >>> do this? >>> >>> I think the solution is to maintain non-persistent nodes which are >>> computed at access time, but I'm not entirely clear. >>> >>> I have no idea why I am posting this to cap-talk. There may be some >>> capability issues that I haven't thought of yet. Or perhaps the capability >>> folks have already solved this. >>> >>> For your consideration, >>> >>> John Carlson >>> >>> >>> _______________________________________________ >>> fonc mailing list >>> fonc@vpri.org >>> http://vpri.org/mailman/listinfo/fonc >>> >> >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> _______________________________________________ >> fonc mailing list >> fonc@vpri.org >> http://vpri.org/mailman/listinfo/fonc >> > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
