Bert Verhees wrote:
>
> 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.
that is true, and I have to admit it is a real annoyance - it is due to
the lack of export control in .Net - the Eiffel people discovered there
is simply nothing they can connect to in .Net that will hide routines
that are in fact hidden in the Eiffel environment ("private" or
"protected" in the language of most developers).
> 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.
agree there as well. Again, we are working on that.
> 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.
yes, that is the openEHR reference model you see there, as .Net classes.
>
> Don't you think this is a violation of OO concepts?
not sure what you mean here - do you mean that more should be hidden?
Apparently the lack of control in .Net prevents this.
>
> 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.
I can't really comment on the above - you are in much deeper into such
issues than I! Apart from the one point that being able to write generic
classes in C# is a massive improvement semantically and in terms of
runtime safety (and it should reduce lines of code as well).
> 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.
I know people say that, but I have never seen it done. It might be
possible with a few core classes, but what you tend to find is that the
Java people say have used Spring, Hibernate etc, and that influences the
code in a certain way, and the .Net people are using say SqlServer 2005,
which makes their code completely different. And a lot of it is about
developer culture, what libraries they know, what frameworks etc. I
don't see that much hope for much direct code translation, but will be
pleasantly surprised if it happens.
>> 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
it does sort of, but in a broken way. (See the terrible explanation in
the UML reference manual - the Booch series book, I forget the title.
It's laughably bad).
> 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.
well, this includes all the Eiffel library classes, parser classes etc,
garbage collector. It probably could be made smaller actually, I am
surprised it is that large - we should do some investigation on it.
> 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.
When we generate the DLL, the Eiffel environment strips out unused code.
But a lot of library classes are used - hundreds. And I have to admit I
don't know the size of the runtime & GC part. I will ask some questions
on this. It may be that we can make it smaller.
>
> 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.
I will point out that even in C# in our company at least we replicate as
far as possible the design-by-contract features - pre-conditions,
post-conditions and class assertions. There is good guidance on the net
on doing this. Designing your code like this saves massively on bug
diagnosis time.
>
> 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.
>
I suggest that the fastest possible paths will be a) the open source
Java implementation, which I think will be upgrade within the next few
months; b) the open source .Net implementation tha Ocean Informatics is
working on in Australia; to be released in the next few months; c)
despite all of the above, I will actually complete an Eiffel
implementation in the next 6 months, and you might like to look at that,
even if oinly for your amusement.
- thomas
