On Mon, Jun 13, 2011 at 9:31 PM, Julian Leviston <[email protected]>wrote:
> I wrote this without reading the very latest > http://www.vpri.org/pdf/tr2011001_final_worlds.pdf so if I say anything > that is obviously missing that understanding, please bear with me :) I'll > read it shortly. > I got wondering about commit failure and cases where you needed certain objects in the world child anyway. Or two different worlds merging. Will that be possible ? NB! A link in document http://www.vpri.org/pdf/tr2011001_final_worlds.pdf didnt work http://www.tinlizzie.org/%CB%9Cawarth/worlds this works http://www.tinlizzie.org/~awarth/worlds/ Karl > > Julian. > > > On 14/06/2011, at 5:26 AM, Julian Leviston wrote: > > > On 14/06/2011, at 4:07 AM, Josh Gargus wrote: > > > On Jun 13, 2011, at 9:35 AM, Julian Leviston wrote: > > > On 14/06/2011, at 1:17 AM, Alan Kay wrote: > > It would be great if everyone on this list would think deeply about how to > have an "eternal" system, and only be amplified by it. > > > Hi Alan, > > You might need to elucidate a little more on this for me to personally > understand you. Not sure how others feel, but the "Worlds" work seems to be > just a description of a versioning pattern applied to running program state. > > > It seems like much more than that to me. > > > Cool :) I'm not saying it doesn't have interesting ramifications ;-) > > > > Why is it especially interesting? In the Ruby community, we have "gem" > which is a package manager and also bundler, the two of which handle > dependency management and sets of bundles of dependencies in context and > situ elegantly and beautifully. Depending on your requirements when writing > code, you can point to "a" version of a gem, the latest version, or say > things like "versions greater than 2.3". It works really well. It also fits > very neatly with your idea of (Alexander's? ;-)) the arch and biological > cellular structure being a scalable system: this system is working in > practice extremely well. (Mind you, there's a global namespace, so it will > eventually get crowded I'm sure ;-)) > > > Consider that in a Squeak image, the compiled methods are reified as > objects. With Worlds, you can make exploratory changes to code in a > *complex running system*, and then back out effortlessly if it doesn't work. > You just throw away the World containing the modified code as well as the > objects that were modified as a side-effect of running the modified code. > > > Yes, I've considered this. One of the things that crops up, though, is what > about "data"? That is to say, what if one of the "world" experimentations > one ends up doing involves experimenting with modifying some of the model of > a particular piece of code... and this necessarily involve mutating a data > type (ie model parent object or "class" implementation)... how does the > idea/system apply to this, especially when considering things from the point > of view of concurrent simultaneous users... where one person may mutate the > state in the discussed manner, but another person is using a different > "world" (a previous one with a different data structure in place)... yet > they both still need to use the same data (ie imagine an address book > application where one person is mutating the model layer live, and both > people are using it live and inputting new data)... > > ... the idea of published / unpublished (ie published being a particular > "world" that is being pointed to as the current "live" one) seems to serve > well here. > > ... also, the idea of modelling change ITSELF is an appealing one in this > context, and all changes including data "entry" etc being simply represented > as a log of mutations using the command pattern. Thus the data represented > in the first "world" would be mutated and "propagated" to the new world > (actually more like the "view" of it filtered or some-such) according to the > new rules, and the inverse would apply as well... > > ... of course, the question of irreversible transactions (ie destructive or > creationist "commands") arises... what to do about when adding or destroying > structure inside a data structure when involving those worlds? (in other > words, the second, experimental world perhaps has added a "title" field to a > person, and then the second world user adds a new person, with the title > field... what does the first world user see?, etc. This is a superficially > simple illustration - add some code to the second world which would break if > things aren't set up in a particular structure, such as a requirement on the > "title" for a person, and then the first world entry not actually having a > title, and we get a bit stickier - this particular example falls apart > rather easily, but you get the gist, hopefully?) > > The worlds idea seems to ignore the fact that the only way to really get > the feel for something is to use it... so an experiment (ie a child world) > would need to be using real, live data... so a "user" or "programmer" would > end up with the painful situation of having to migrate their created > application objects - the "data" - back into the parent world but not > migrate the code back if the experiment failed... *or* they would have to > treat the experimental world as experimental only and not "real", but doing > this wouldn't actually allow one to know whether the experiment was working > or not... *or* they'd have to use two worlds simultaneously - the first, > un-experimental world to just use their application, and the second world to > test things out until they were happy that it would work as they anticipated > (ie the experiment worked). > > Either way, it could bear more thinking... > > Julian. > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > > > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
