paj@mrcu (Paul Johnson) (12/14/90)
As I understand it, the reason Eiffel does not have enumerated types and did not originally have an `inspect' statement is that if you are using these facilities then you are doing it wrong. Your inspect clauses should be split up into separate classes which inherit their interface from one base class. The dynamic types of the object instances then replace the values of the enumeration. This is what distinguishes OO programming from structured programming. The only time inspect statements are needed is when doing things like processing input or interfacing to C code written with case statements in mind. On the other language design points, I think a type ADDRESS would be a Good Thing. OK, its dangerous, but no more so than INTEGER, and some more elegant interface to C which does not require external libraries for trivial jobs would be a good idea too. Paul. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
rick@tetrauk.UUCP (Rick Jones) (12/18/90)
In article <755@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: >As I understand it, the reason Eiffel does not have enumerated types >and did not originally have an `inspect' statement is that if you are >using these facilities then you are doing it wrong. Your inspect >clauses should be split up into separate classes which inherit their >interface from one base class. The dynamic types of the object >instances then replace the values of the enumeration. This is what >distinguishes OO programming from structured programming. > >The only time inspect statements are needed is when doing things like >processing input or interfacing to C code written with case statements >in mind. Another important use of inspect statements is when you are at the decision point where you need to choose which of the possible sub-classes of a base class is to be created. Polymorphism can look after everything from then on once the objects actually exist, it's where the instances have to be created that a bit of messy conditional code sometimes seems unavoidable. I feel that a good rule for inspect blocks and the like is that there should only be one place (i.e. one routine in one class) where a selection is made among a given set of choices. If this set of choices is going to result in other effects later, then the result of the choice must be to create an object of an appropriate class, where the other effects are implemented as redefined routines. You then never have the problem of keeping multiple inspect blocks in sync. (which is the real problem). >On the other language design points, I think a type ADDRESS would be a >Good Thing. OK, its dangerous, but no more so than INTEGER, and some >more elegant interface to C which does not require external libraries >for trivial jobs would be a good idea too. Glad you agree! -- Rick Jones Tetra Ltd. Maidenhead, Was it something important? Maybe not Berks, UK What was it you wanted? Tell me again I forgot rick@tetrauk.uucp -- Bob Dylan