2017-08-17 6:51 GMT-03:00 Esteban Lorenzano <esteba...@gmail.com>: > > On 17 Aug 2017, at 11:34, jtuc...@objektfabrik.de wrote: > > Am 17.08.17 um 11:31 schrieb Esteban Lorenzano: > >>> On 17 Aug 2017, at 11:28, jtuc...@objektfabrik.de wrote: > >>> > >>> Herby, > >>> > >>> back when Alan was maintaining Glorp, he took care for portability, he > >>> even maintained the port to VA Smalltalk, IIRC. Niall and Tim(?) at > >>> Cincom also try not to break any dialect in their changes and they also > >>> work on keeping things portable. I am not sure there ever was any > >>> (semi-)automated process to keep ports in sync, my guess would be that > >>> that is not the case. > >>> > >>> What I am very sure of is that the ppl at Cincom would welcome any > >>> volunteers to support them in keeping things portable and improve the > >>> ecosystem for this. > >>> Is any of you going to be at ESUG? > >> I will, but I will not maintain Glorp port… I have just too much work :) > > Same for me. I am not a regular Pharo user, so I cannot do it. > > yeah… too bad :( > “unofficial maintainer” of Glorp port is Esteban Maringolo. But since he has > to make a living (and right now he is working on VW, not Pharo), he cannot do > it but lightly. > Other maintainers should be the people using it, so the addition of Herby is > welcome (Esteban M. will check at when he has time… but at least now is > available for other people to check).
Glorp was built with portability in mind, but it's too "old school", the packaging itself is a nightmare. And most of the design, and "portable" parts are designed around VW database layers. The code sharing is a thing in its own, I had to "adapt" a Monticello exporter in VW to get better package names instead of a single "Glorp" package. FileTree is stilll not available in Cincom, Martin McLure said they're working in a new Cypress spec that'd work in VW as well, I look forward to see that, because I'd need it to move code back/forth Pharo and VW. Last year I did a port to Pharo from the latest availalable version in Cincom and tried to keep both in sync, but the feedback loops are quite different in Pharo than Cincom, skillsets are also different (I'm still struggling with Store), and even with some support, Cincom doesn't have portability as a main objective, Glorp today is a means to and end, and that end is their SCM, Store. So modifying a core tool just to be more portable is not a priority for them. Also the way Glorp is made portable is very differently from how Seaside is done, Glorp has a lot of #isVW, #isSqueak, #isPharo, etc... which I removed from the latest port. The last time I did not dare to "hard-fork" the whole project and refactor it, maybe the next time. > I myself keep track of my own beast: Voyage… but thankfully I can just check > time to time since we have a small but active community around it. Ideal > situation for Glorp would be having the same. I'm a "happy"[1] user of ORMs, and used them in Smalltalk for over a decade (in Pharo for a couple of years), unfortunately for Glorp, I've been coding for GemStone based projects and now also Glorp but in VW, with SQLite for a minimal part of the application. So, bottom line, it takes me some time to catch-up and get into ORM "mode", since it's something I'm not doing every day. Best regards! Esteban A. Maringolo
