Hi,
It seems to me you are turning around a really subtle and complex concept.
Like a building, information systems must have some hard parts (to stand
up) and a flexible content (so you can live in it).
The usual way is to have the "hard parts" being whether a database model
or some pieces of code, or the both of them. The flexibility is very
low, and I am used to saying that these systems can only tell one story,
but it is neat and usual for programmers.
Now comes the "2 levels" systems, where "what can be told" is not mixed
with "what can tell it".
Some examples of components of the kind I have been working on :
- Archetypes, of course, to separate the data model from the code and
the database
- Data querying, with such tools as the Pilot that uses XML scripts to
describe a query workflow, instead of hard programming SQL or Corba or
Web services connectors
- Security components, with such a project as MP6 where the rules are
expressed in a predicate language with a genuine abstraction from the
software code
One of the key advantage (among many others) of these 2 levels systems
is that we can build "proof components" for the model itself and not
just test if the software is bug free. This is the genuine "hard part"
of our modern buildings.
Thomas is trying to express that Eiffel is not used as a programing
language here (even if it could be, but it can be confusing) but as a
way to express and validate some concepts.
However, living in Paris, I can assess that Eiffel is such a good
programing language that we have here a quite impressive monument raised
to glorify it. And we don't have any Java tower or C++ tower or any
other tower of the kind.
Cheers,
Philippe
Thomas Beale a ?crit :
> 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
>
>
>
