Bert Verhees wrote:
>
><example>
>A class has an "interface", this what it makes visible to other classes. A
>property is some characteristic of a class.
>F.e a class Person has a property bodyLength. This can be in inches or
>centimeters. For example bodyLength can give you centimeters or inches,
>depending on which Local is configured:
>
>In java one publishes the getters and setters, they do not use properties
>often,though it could be possible.
>In object pascal one publishes the property, and private implements the
>getters and setters, they do not have to be public or published, the
>compiler arranges the connection. One can also publish the getters and
>setters in object pascal
>In Eiffel I don't know.
>
>
In Eiffel you can do what you want, but you normally publish attributes
and setter routines. Getter and setter routines are bad programming
practice, since they destroy any proper connection of the code with a
model. For example if the model is (pascal-style):
class PERSON
name: String
end
then you can just add the setter to the class to have an operational class:
class PERSON
name: String
set_name(a_str: String) is
do
end
end
But with the getter/setter style you end up with classes like:
class PERSON
get_name: String is
do
end
set_name(a_str: String) is
do
end
end
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.
>As you can see on the pseudo-code below, I am used to Pascal, Java and C(++),
>I mix them so anyone can understand. I call it Jascal++ ;-)
>
>
even I can understand it
>const BRITISH = 0;
>const OTHER=1;
>
>class Person{
> public property bodyLength:Integer read getLength;
> public property Local write setLocal;
> private function getLength:Integer;
> private procedure setLocal(value:Integer);
> private fLength:Integer;
> private fLocal:Integer;
>}
>
>procedure Person.SetLocal(val:Integer);
>{
> fLocal:=val;
>}
>
>function Person.getLength:Integer{
> if fLocal=BRITISH then Result := fLength/2.54
> else Result := fLength
>}
></example>
>
>In a case tool, only the class-interfaces is mentioned, and in a short way,
>eventually documentation added.
>In a case tool a class would look like
>
>Person
>----------------
>bodyLength:Integer
>Local:Integer;
>
><comment>
>(In XMI one would get about the same (but then in XML).
>A case-tool can load the XMI, and generate code following the syntax and
>programming standards of that particular language.
>I know there are shortcomings in XMI, but still I think, it is better then
>nothing, in accompanying docs, want could explain the shortcomings. Most of
>the classes and their particularities can be expressed in XMI)
></comment>
>
>The implementation-part is in the code, never seen implementation-parts in a
>case-tool. It is possible, but rarely done.
>
>When you use a case-tool which is at the same time a programming-enviroment,
>then you can eventually compile the code, but there will be no implementation
>behind the class-properties/methods, and in the compiled product, it is hard
>to discover which property/method has implementation-code behind and which
>not. Escpecially when it is not explicitely said.
>
>
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).
>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.
>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).
>
>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.
>I can understand, that using Eiffel in this way has a lot of advantage for
>you, but for people using other programming environments it is difficult.
>So interoperability to other programming environments is not so good. This is
>a bit of a vendor lockin, or better said, to a programminglanguage-lockin
>
>
I still don't understand the problem. You don't have to use the Eiffel
code at all. It is an extra thing in the openEHR environment that we
simply use to validate models. You can ignore it completely if you want.
There is nothing special about it from an implementation point of view.
><eiffelstudio>
>One is stuck to a certain environment.
>I downloaded the community-version of Eiffel-studio 5.6, and I really had
>problems to get the thing going. And I am used to many IDE's, Visual Studio,
>Borland-IDE's, KDevelop, and more. Also worked a bit with Eclipse.
>Mostly it is simple, start a project, create new classes or add existing ones
>by adding sourcefiles.
>Eiffel Studio does these thing a different way, even in the helpfile there is
>no entry which says: "Add a source file to a project."
>I used it a few hours, then went back to tools in which I am much more
>productive.
>I can get used to it, but I must say, it is not very intuitive for me to work
>with.
></eiffelstudio>
>
>
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.
>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.
>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.
>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!
>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.
>
>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.
>Also there is a need of more ITS and example projects. There is f.e. no
>persistence layer and no example GUI-layer, and though there is a lot of
>documentation, it is hard to get the pieces together. It takes weeks to read
>and understand the complete docs, after one must start programming, with bad
>luck, from scratch.
>
>
sure, that's true. These things will take time. We've just developed the
equivalent of a standard for the EHR, now we (the community) are doing
the code...
>At this moment OpenEhr seems to me more like a OpenConcept-project instead of
>an OpenSource-project.
>
>
I consider it an open specification and open source project.
>
>I did not find a project which does the complete implementation. maybe I
>missed it.
>
>But reading further, i can see that I have to wait. That is a bit of a
>problem. It is not that I am on a day to day schedule, but some investors
>want to have some time-schedule.They do not want to hear something like
>somewhere next year.
>
>
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.
>
>>From your other email:
>
>
>
>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
>
>
it does work, but I am not convinced it exports generic types properly.
I have not used it since we stopped using Rational Rose (which is just
far too expensive to continue using).
- thomas beale
