rick@tetrauk.UUCP (Rick Jones) (05/30/90)
In article <331@eiffel.UUCP> potter@eiffel.UUCP (John Potter) writes: >I am curious to hear opinions about the use of selective export in >Eiffel. > >If anyone out there uses selective export, in what context? > >I've been trying to think of a good use of it, and I can't find one. If >there are no good uses, then I guess it should not be part of the >language. > >Any opinions? > Yes, there is a very good reason for restricted exports, and they are used in several places in the standard Eiffel library. A perfect example is the way the LINKED_LIST class is implemented. This uses a second class LINKABLE, which provides the glue used to link the real objects together. The existence of LINKABLE is a pure implementation detail, has nothing to do with the semantics of LINKED_LIST, and is never seen by the client. LINKABLE can be considered a "slave class" of LINKED_LIST, and is only there as an implementation mechanism. As we all know, implementation details should be hidden from clients. If the features of LINKABLE were publicly exported, it would all still work, but you could find that a client programmer, either through ignorance or being "clever", used the LINKABLE class directly. This would then prevent the LINKED_LIST class being improved in future in such a way that affected the private interface. Someone might even be smart enough to find a way of building LINKED_LIST without needing the additional LINKABLE objects! In other words, its just a logical extension of the hiding principle, and can/should be used in cooperating application classes as well as library stuff. In article <1434@enea.se> sommar@enea.se (Erland Sommarskog) writes: > >(*) This is a thing I don't really like. If I say > > export > Some_feature(ANOTHER_CLASS) > >the followning piece of code is illegal: > > A : THIS_CLASS; > ... > A.Some_feature; > >I have to add THIS_CLASS to the export clause above, and for every >single feature. To me it seems of little value to restrict export >to the class itself. Thus, a class should always export to itself. > -- I though this was excessive when I first came across it, but on reflection it is in fact necessary. Secret features of a class are there for exported routines to use *in relation to the current object*. If the current object refers to any other objects, they may only be accessed via that class's exported interface. The fact that a reference may be to an object of the same class as the current one does not imply any special priveleges, it is still a different object. If the fact that it may be an object of a descendant class is also considered, the problem of allowing unrestricted access becomes even clearer. It is just an extension of the situation I described above - if a class needs to have some private arrangement to access objects of the same class *apart from the current instance*, the features must be selectively exported to itself. -- Rick Jones You gotta stand for something Tetra Ltd. Maidenhead, Berks Or you'll fall for anything rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick) - John Cougar Mellencamp