Tim Cook wrote: > On Thu, 2006-02-02 at 10:01 -0600, Bill Walton wrote: >> Does anyone have any experience with / opinions about the suitability >> of Ruby and Rails as implementation platforms for openEHR? >> > > Some of us always have opinions. ;-) > > I think the biggest drawback in using Ruby is the lack of multiple > inheritance. > > However, Ruby lovers will argue that using mixin classes can achieve the > same thing and that multiple inheritance is a source of confusion. > > I *do* think it makes sense to use existing, tried and tested > frameworks/components as part of an infrastructure where possible.
Ruby is probably a reasonable choice for implementing openEHR, and many people who are sick of Java and/or Perl seem to like it a lot. Despite the lack of multiple inheritance, it is in some ways more object-oriented than Python, but in ways that don't seem to matter a great deal (to me, at least). The syntax looks too much like Perl for my liking, but that's just personal taste. Python is better established and has a larger community, but Ruby is catching up. However, Ruby on Rails as a platform for openEHR is another matter. Ruby on Rails (RoR) is a high-level framework designed to make certain constrained classes of database-driven Web apps much easier and faster to implement. RoR is based around an object-relational mapping layer designed for CRUD operations, and the whole thing is driven by it. Thus, to implement openEHR, you would need to replace the very heart of RoR with an openEHR storage/retrieval engine. Probably doable, but the result would not be RoR (it might be openEHRuby...). Like all high-level frameworks, if what you want to implement fits the framework model, then RoR (and its Python equivalents, Django and TurboGears) can be a tremendous boon. But if not, then they just get in the way. Tim Ch
