> For example. In order to convert an instance of A to an instance of B > we have to have a persistent function.
Let's stop right here. Why that? What I had in mind was that the programmer keeps around, say, a file full of those conversion functions, thereby providing legacy support for her data structures. > Perhaps rather than an implicit feature, we provide a toolkit for > making user schemas easy to build. This could make it easy to > create, compare and perform operations on schemas from classes and to > hook into the MOP to extract them and use them in class redefinition > and creation. We could provide an inherited slot for class instances > that keeps a pointer to the schema. Users that are afraid of this > functionality can just choose to update manually so that consistence > is guaranteed. Trading off performance for a strong guarantee strikes > me as the better default behavior. I don't understand what you have in mind here. Perhaps it would help if you explained the idea of a “user schema” in more detail. Then again, I don't think this is a thing that is of interest to me right now, so you might not want to explain this further and save your time. > I'm happy to support this effort if you or someone else are interested > in taking it on, though. Thanks a lot. I'll do what I can. I must balance between the needs of my project and Elephant, though. Leslie -- My personal blog: http://blog.viridian-project.de/ _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
