Hi Thomas, there was alreay a lot of communication in the list, and I answered to some issues in other messages, but there are some points I want to reply to, for discussion purpose.
Thomas Beale wrote: > <snip> > which is ridiculous in terms of modelling - there is no sensible > property of a PERSON called a "get_name". Sadly this kind of > programming has become commonplace. That is true, it is done a lot in Java, in most other languages, there are getters and setters but the compiler and private-visibility hides them. But even in Java it is not a real problem, because when you have an XMI-file or other way of class-description as you like, you just define Person.Name:string, the code generated out of the XMI repaires that, if it is a good code generation tool. Only the programmer will see public string Person.Get_Name: but has no problem with that. It does not really break OO concepts. >> <snip> > > not sure what you mean here. All our Eiffel implementations are > complete implementations. We haven't finished the kernel (at all) but > the ADL parser is interfaces with code behind that compiles to a > running tool, including GUI (the ADL workbench is 100% Eiffel code). That is good, this means we can trust the dotnet-dll's. I already loaded them in Borland dotnet studio, and everything seems to publish itself as it should. The only thing is that seems to Eiffel publish a lot more then you programmed. I am not sure what to do with it. It looks like there is a lot of default Eiffel-code published. Must initilialize something, finalize something, I don't know. These are problems easy to overcome, a bit of documentation can make a lot of difference. You can see what I mean here: http://www.rosa.nl/eiffelindelphi.gif I made a screenshot. Only the published part with red line is openehr code, as I guess. Don't you think this is a violation of OO concepts? > >> When I find a DLL, which is compiled code, one could assume, it has >> all the implementation-code in it, why would one else compile it. But >> the user of the environment as a case-tool may also want to compile, >> just for checking for errors. >> >> > well that's true, but they wouldn't normally bother to generate a DLL > and publish it - there would be no point. You never know ;-) what one does and why, no offence. But now I know > >> So in this mixed case/programming-environment it is possible to find >> a dotnet-dll, which is large, publishing all the classes, but has no >> or not all implementation-code. >> >> > technically, that is true, but no-one I know does that. We only > generate DLLs or other executables when they actually do something. > Otherwise, we just build test programs to test the classes. That's how > we know the openEHR models are valid - they are always tested in > Eiffel. We couldn't do that in other languages because we would have > to mangle the model so much just to get it expressed that we wouldn't > be validating the model, we would be validating a xxxx-implementation > of it. > > This doesn't mean you can't write good (or even great) software in any > other language - you can - it's just that that software will be a > certain transform from the original model, and some parts of the > transform are human-determined, due to limitations of the various > languages (e.g., lack of genericity in both Java and C# until recently). Glad you point to the genericty possibly now, which is important. > >> >> Then I understand that the Eiffel-code has its implementation-parts >> worked out. <comment> >> The dotnet-DLL could then be used in a project. Maybe it even can be >> used in Mono, because there want be much Windows-API-stuff in it. >> Depending of course on the dotnet-version. I think the OpenEhr kernel >> does not take advantage of dotnet 2.0, so for compatibility reasons >> one could stick to dotnet 1.1, for the time being >> </comment> >> >> > a .Net kernel built from Eiffel code can just be recompiled in teh > next version of EiffelStudio, and you will get .Net 2.0 assembly - no > extra work to do. The hand-built one from Ocean Informatics is .Net > 1.1 now, but will target .Net 2.0 this year. This is very good, but the features of dotnet 2.0 do not effect the openehr concepts, as for now, mathematical calculation performance of dotnet 1.1 is better then native compiled C-code, because it is compiled just before use (JIT) and against highly optimised libraries. Which not always is the case in Borland C 5.5 which Eiffel Studio uses now for Win32 platform. Dotnet 2.0 does not change that much. It adds language features and GUI-feautures. Special LINQ is a powerful new feature, but it will come in dotnet 3.0 and is only usefull in Relational DB's which we al hate and need. Knowing Microsoft it could degrade the dotnet 1.1 libraries so to push people to dotnet 2.0. Dotnet 1.1, as said is compatible with Mono, which makes it a good platform to write software in, and it supports many programming languages. The only problem I am aware of in Mono is that it has a problem with fancy GUI's, but that is not the issue in OpenEhr. >> <snip> >> > I can't comment here - I find it about the same efficiency as eclipse. > Eclipse definitely has better screen real-estate usage. But then every > time I have shown anyone how you can browse a system in Eiffel, > including classes in inheritance-flattened view, interface view, > attribute view, routine view, clients view, suppliers view, and > properties & routines in callers view, inheritance-flattened view, > they are always amazed. Most of these views just don't exist in most > other environments. But again, there is no reason for you to spend any > time with Eiffel if you don't like it - just ignore it and work in > Java or Delphi. Maybe next time we meet somewhere, I'll bing my notebook, and you show me in a glance. ;-) > >> And since the "case-tool" Eiffel can only generate Eiffel-code, users >> op other programming environments have to completely rewrite the code >> from scratch. >> >> > But that's always the case. When the C# people saw the Java code, it > didn't help them. They rewrote it in C#, using all different > libraries, unit test frameworks etc. That's the reality of the world > today - everyone loves rewriting all the time. I don't even bother > mentioning that I can easily deploy Eiffel on any platform with just a > recompile, or that I can build a .exe, a .dll, a .so or whatever. I > can also make the Eiffel code integrate with C or C++. But everyone > wants to write code in their favourite language rather than re-use > components. And realisitically, given how hard it is to make Java talk > easily to other components, it's not surprising. And it's probably > reasonable anyway - people need to use the skills and tools they know > and just build things. I don't expect that even if there was a full C# > implementation of the kernel that many Java people will look at it. > THey mostly won't even have Visual Studio on their machines. It is not that difficult to migrate from Java to C#, mostly. Just re-engineer the java-files in rose and generate C# code. You get getters and setters, maybe, I don't know, maybe rose solves that, so there will still be work to do, but it really makes a difference if the class/method-frameworks are generated. > >> If one could use an XMI-model, which is an OMG-standard, one could >> easily import/generate the code/classes and use them in an IDE and >> language of choice. Most programming languages have a way to connect >> to XMI. >> Still there will be a lot work to do, but much less then now, and one >> can easier, and is also forced more to follow the code-concepts. >> >> > that is nice theory, and I wish it would work too, but the UML 2.0 > meta-model is sadly quite broken and doesn't support all the semantics > of all the languages. It is true that it does not support generic types (I believe, I have only experience with UML2.0 for building classes and using OCL), but if so, one can repair that by hand afterwards, just a document to mention the erreneous spots will do. Still there is a lot of work saved. And a lot of interoperability won. The adl_dotnet_lib.dll is 5 Mb. This must be because of a lot Eiffelcode from which I do not know what it serves, and why it is published. The same library in C# would be less then 10% large. Not used code is dangerous, it can contain vulnerabilities or cause unexpected situations, one can never know, because one did not write it. Every unused line of code should be avoided. > > >> I understand from a previous mail from you years ago, there are two >> main advantages of Eiffel, multiple inheritance and the use of >> generic template-types. >> >> > there are others: design by contract is the main one. Agents are also > very powerful (like C# delegates). THe inheritance semantics are also > very powerful, and simple compared to other languages. But I still > don't understand why you are making the comparison - you can > completely ignore Eiffel and just use another language! Many more > people are working in Java and C# on openEHR than in Eiffel! These are powerful features of Eiffel, I did the comparison because I was wondering why Eiffel, but you explained. There are advantages, for sure. So maybe the discussion is not that interesting in this situation. > >> For many languages, Java and object pascal, and also C# are solutions. >> More or less elegant. As ACode proves, it is possible to write the >> kernel in Java, this is good news. It maybe possible to write it in >> other languages. Though, I had problems importing the code in Rose >> and in magicDraw, for re-engineering purposes, but I did not really >> try hard. Maybe it is possible. >> >> > Sure it is possible. I am sure I could write it in ANSI C. The problem is that I do not have the time to rewrite the kernel in another language which is more convenient for me. I am studying OpenEhr for a project with not a large budget. Sometimes I wished I worked for a university and could spent a year or so in rewriting this. This is not the case. If we find a more or less easy way to implement OpenEhr, we will seriously consider it. > >> >> If it was possible to export the code-concepts in a >> vendor-independent way, Openehr could become useable by much more >> programmers. >> This would really speed up the coming of open source implementations. >> >> > well again, this is limited by UML 2.0, current UML tools (really , > not very good), and lack of interoperability between languages. I > don't know what can be done about this. It is true, it seems that the builder of those tools never heard of OMG. But often, when the original code is at hand, and specially if one is noticed to possible errors, one can repair things, as I said before. I discussed before > <snip> > I consider it an open specification and open source project. > well, if they just want a running system, they can get one elsewhere > faster. But if they are thinking in a 5-year time frame, waiting a bit > might be useful. THey won't get archetypes or an open EHR data model > and interoperable (and CEN-compliant) schemas elsewhere that I know of. It seems Acode has done a good job already, I learned from an email published after this in this group >> By the way, I saw in the Eiffel Studio a menu-option: Export To XMI. >> Could that be useful? Is it possible to do those basics things here > Give it a try, and send me the XMI, just for fun, but I am afraid, I did it with a default project from eiffel, al the classes I did not ask for are in it also. So, maybe it is not very useful. regards Bert Verhees
