J. Lamping. Typing the specialization interface. In Proceedings of OOPSLA, 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....This paper observes that Abstract classes containing template methods are especially useful when several concrete classes provide alternate implementations of the same abstraction. Some of the same issues that motivate this pattern were also discussed by Lamping at least as far back as 1993 [3]; this paper also uses the the name core methods to refer to those that access the instance variables of the representation directly. The set containing the remaining methods is not named, but these methods are given a type that explicitly distinguishes the protocol that a method uses on self ....

John Lamping. Typing the specialization interface. In Proceedings Eighth ACM Conference on Object-Oriented Programming Systems, Languages and Applications, 1993.

....have [103] That is, one must specify for each component the services it o#ers to other components and also the services it requires from other components. These services are usually specified as contracts between the parts. Reuse contracts [50] an extension of Lamping s specialization clauses [63], were defined and developed as enhanced interface descriptions for sets of collaborating participant components. Hierarchies of components contracts were defined [14] in order to check a component behavior before using it. This feature is important due to the late integration of components. Since ....

J. Lamping. Typing the specialization interface. In Proceedings of OOPSLA '93, pages 201--214. ACM SIGPLAN Notices, 1993.

....and show such information to developers. In Section 4 future work and final remarks are listed. 2 Introducing Dependency Information in the Module Interface 2.1 Adding Dependency Information Inheritors should know about the dependencies among methods. In order to cope with this problem Lamping [4] proposed to enrich module interfaces with information reporting the dependencies among class features. The rationale behind this suggestion is to provide inheritors with enough information about how the features of a class combine to produce its overall behaviour, so that programmers fully ....

J. Lamping. Typing the specialization interface. ACM SIGPLAN Notices, pages 201--214, 1993. OOPSLA'93.

....Implementations or interactively during execution. However, this might be complicated for several reasons, starting with the fact that we want the details of an assembly to remain hidden once it reenters the assembly phase, but refining is difficult without having access to the assembly details [7]. Another reason is that this might create unwanted dependencies between components. Work is in progress to try to give an answer to these questions. Finally, other members of our research team are studying other important aspects of component models, in particular there is work in progress to ....

John Lamping. Typing the Specialization Interface. In Proceedings of the OOPSLA '93 Conference on Object-oriented Programming Systems, Languages and Applications, pages 201-214, October 1993. Published as Proceedings OOPSLA '93, ACM SIGPLAN Notices, volume 28, number10.

....given by the concepts, we could understand how the classes are related using different criteria. In our case, we analyzed two specific features of a class hierarchy: inheritance and interface. 3. CASE STUDY 3. 1 Terminology We will first introduce some terminology (similar to the one used in [8]) that will be needed for the rest of the paper: The client interface of a class is the set of all selectors that are implemented in the class and to which direct sends can be made[8] In Java, the client interface is the set of all public methods. In Smalltalk, the client interface is the set ....

....3. CASE STUDY 3. 1 Terminology We will first introduce some terminology (similar to the one used in [8] that will be needed for the rest of the paper: The client interface of a class is the set of all selectors that are implemented in the class and to which direct sends can be made[8]. In Java, the client interface is the set of all public methods. In Smalltalk, the client interface is the set of all methods (since there is no visibility mechanism in Smalltalk) The subclass interface of a class is the set of all selectors that are implemented in the class and to which ....

J. Lamping. Typing the specialization interface. In Proc. Int'l Conf. Oject-Oriented Programs, Systems, Languages and Applications (OOPSLA93), volume 28 of ACM SIGPLAN Notices, pages 201--214. ACM Press, October 1993.

....and documents the core behaviour of the class. This can be used to distinguish the core methods of a class from the auxiliary ones. This is important information for reusers because, if the core methods are overridden in a subclass, all auxiliary methods will still work correctly with the new core [10]. m1 . mp . self m1 . self mp . B . self mp n . B mp . m1 . Fig. 4. Concept Pattern 2 For our experiment we computed a static approximation of the self sends and super sends. For example, even if sends ....

J. Lamping. Typing the specialization interface. In Proc. Int'l Conf. Oject-Oriented Programs, Systems, Languages and Applications, volume 28 of ACM SIGPLAN Notices, pages 201--214. ACM Press, October 1993.

....for designing specialization interfaces, but they concentrate on layered control abstractions and do not discuss class components, abstract representations or representation categories. Control abstractions go back to Simula, where they are part of the programming lore (see, e.g. Pooley87] [Lamping93] presents static checking for control abstractions. Lamping93] anticipates the idea of class components, but it fails to distinguish them from control abstractions. Lamping s later paper on checking specialization interfaces [Lamping94] deals purely with control abstractions. The Standard ....

....on layered control abstractions and do not discuss class components, abstract representations or representation categories. Control abstractions go back to Simula, where they are part of the programming lore (see, e.g. Pooley87] Lamping93] presents static checking for control abstractions. [Lamping93] anticipates the idea of class components, but it fails to distinguish them from control abstractions. Lamping s later paper on checking specialization interfaces [Lamping94] deals purely with control abstractions. The Standard Template Library of C [Musser96] makes extensive use of control ....

J. Lamping. Typing the specialization interface. OOPSLA '93 Conf. Proceedings (Washington, DC. Oct. 1993). Published as SIGPLAN Notices, 28(10):201--14. ACM, Oct. 1993.

....also involves a form of decapsulation. They argue that breaches of encapsulation by message passing clients can be inhibited if a clear distinction is made between inheriting clients and message passing clients. Inheriting clients access an object through its specialisation interface (cf. Lamping 93] exposing implementation details of the object important for inheritors, e.g. which method is called through self sends by what other method 1. On the other hand, message passing clients can only access an object through its client interface, i.e. the set of all messages understood by the ....

Lamping, J. - 1993. Typing the Specialization Interface. OOPSLA '93 Proceedings, pp. 201-214, ACM Press.

....the cardinality of the set is even. A programmer could think that it is still possible to build a set with an even cardinality by using AddAll( Unfortunately, AddAll( relies on Add( and it can, at most, add the first element. 2. LAMPING S PROPOSAL In order to cope with this problem Lamping [5] proposed to enrich the I interface with dependencies among class features. The rationale behind this suggestion is to provide inheritors with enough information about how the features of a class combine to produce its overall behavior, so that programmers fully understand the consequences of ....

....Method1( to override Method2( also, because it relies on Method1( This example, while artificial, is representative of a large class of real problems that can be solved by exploiting our approach. DependencyAttribute( void Method1( 5. RELATED WORKS The work of Lamping [5] forms the conceptual basis for the approach described in this paper. The importance of internal dependencies and the need to document them was stressed by other works of Lamping et al. 4, 3] where they advocated the use of a specialization interface, di#erent from the use one. Specialization ....

J. Lamping. Typing the specialization interface. ACM SIGPLAN Notices, pages 201--214, 1993. OOPSLA'93.

....support for delegation based component interaction. Secondly, components to be composed by delegation depend on the specialization interface of their parent components. Therefore, further advances of component interface specifications are required, which make its specialization interface ([18]) or reuse contract ( 22] explicit, along with other work aimed at solving the semantic fragile base class problem ( 20, 24, 27] Finally, the impact of language support for delegation on general design patterns, component design methods, component description languages, component ....

J. Lamping: "Typing the Specialization Interface", Proceedings OOPSLA '93, ACM SIGPLAN Notices, vol. 28, no. 10 (1993), pp. 201-214.

....structure, as anyone who has cut and pasted software code can testify. Creating new classes through inheritance can pose a similar problem, since object oriented languages do not support the specification of an explicit, typed inheritance interface for programmers who develop subclasses [23]. Putting together components is much simpler, due to a well defined composition interface that defines how components may be plugged together. What, if any, are the differences between objects and components First of all, objects encapsulate services, whereas components are abstractions that ....

....violation of encapsulation poorly understood violation of encapsulation inadequate characterization Figure 3 Interference of OO Features 11. Beyond Objects: Components construct (called inner ) that can be used to control exactly where subclasses may extend inherited behaviour. Lamping [23] has proposed a discipline for explicitly typing the inheritance interface, which goes a long way towards turning inheritance into a black box form of reuse. Bracha [4] has proposed a finer granularity approach to class composition based on composition of mix ins. Mix ins are comparable to ....

John Lamping, "Typing the Specialization Interface," Proceedings OOPSLA 93, ACM SIGPLAN Notices, vol. 28, no. 10, Oct. 1993, pp. 201--214.

....support for delegation based component interaction. Also, components to be composed by delegation depend on the specialization interface of their parent components. Therefore, advanced component interface specifications and approaches to the semantic fragile base class problem are required ([Lam93], Ste96] Mik97, Szy98, Wec97] ....

Lamping, John. Typing the Specialization Interface. Proceedings OOPSLA '93, ACM SIGPLAN Notices, 28(10):201--214, 1993.

....In [11] the conflict between inheritance and encapsulation is resolved by reverting to a weaker definition of encapsulation, which distinguishes between message sending clients and inheriting clients. Inheriting clients are presented a larger interface, often called the specialisation interface ([7], 12] Implicitly, the specialisation interface of a class is the external interface extended by all methods called via self in the class and its superclasses. This definition requires the code of a class to be inspected in order to determine its specialisation interface. For practical reasons, ....

J. Lamping: "Typing the Specialization Interface", Proceedings OOPSLA '93, ACM SIGPLAN Notices, vol. 28, no. 10 (1993), pp. 201-214.

....the additions. If the implementation of addAll does not use add but immediately adds all methods, then CountingSet needs to override both methods. Several approaches were taken to alleviate these problems and provide more constrained forms of white box reuse (such as specialization interfaces [11] or reuse contracts [12] The design pattern movement aimed at providing a better way of documenting, communicating and reusing solutions to common design problems [8, 5] like the (active) cookbook approach before it [10] Other composition mechanisms were investigated, such as Aspect Oriented ....

J. Lamping. Typing the specialization interface. In Proceedings OOPSLA '93, ACM SIGPLAN Notices, pages 201--214. ACM Press, 1993.

....to provide only such reimplementations that would not violate these declarations. The focus of our discussion are declarations of functional protocols, which are protocols that do not depend on the internal state of the receiver, but only on parameters and eventually on some global values [11, 13]. In Smalltalk context from which the example is taken, we consider as functional protocols that depend on class variables as well, since the latter generally do not change after having been initialized. By declaring part of a protocol as functional, the implementor in effect makes a contract ....

John Lamping. Typing the specialization interface. In Proceedings OOPSLA '93, ACM SIGPLAN Notices, pages 201--214, October 1993.

....to evaluate the usefulness of the proposed architecture in different open implementation scenarios. Currently we are working on applying the model in the context of programming languages, for providing metaprotocol based mechanisms that support an explicit (encapsulated) specialization interface [7, 8]. The next step will be its application in the operating systems area and other domains where adaptability and dynamic redefinition is an issue. Second, the implementation of the functionality of the proposed model must be completed and evaluated to determine areas for possible performance ....

John Lamping. Typing the Specialization Interface. In Proceedings of the 8 th Conference on Object-Oriented Programming Systems Languages and Applications, volume 28(10) of ACM SIGPLAN Notices, pages 201-- 214, 1993. 26

....the efficient implementation of the base module is based are not maintained by the inheritor. This trade off between easy reuse and efficient implementations has been discussed by Kiczales and Lamping in [11] The problems outlined above have recently attracted the attention of several authors [9, 11, 13, 14, 24]. However, the existing approaches deal only with one category of problems and ignore the other. The approach proposed in [11] is based on informal descriptions of complex protocols which should be considered by the inheritor. Other proposals [9, 23, 24] approach the problems by means of formal ....

....libraries and providing a better methodology for reuse. As argued by Minsky [20] because of their global nature, manual implementations of implicit protocols are not only hard to be realized by the inheritor, but also unreliable, unstable and difficult to verify and to change. Other proposals [13, 14] make use of type systems, or tools built on top of design languages, in order to support the detection of some problematic cases of the first category. The first contribution of this paper is the uniform treatment of both problem categories, based on the observation that the composition ....

[Article contains additional citation context not shown here]

Lamping J. Typing the Specialization Interface. In Proceedings of OOPSLA '93, ACM SIGPLAN Notices, Vol. 28, No. 10, pp. 201--214, 1993.

....results as, for example, methods that are overridden in the inheritor methods can be accidentally invoked by methods in the parent component. An example of another kind of problem will be given in section 3. In an attempt to tackle these problems specialisation interfaces were introduced [Lamping93] (see also [Stata Guttag95] A specialisation interface describes which methods invoke which other methods in a class through self sends. This documentation can be used by programmers of subclasses to assess the effect of overriding a method, without having to inspect all implementation details ....

Lamping, J: Typing the Specialization Interface , In Proceedings of OOPSLA `93 Conference on Object Oriented Programming, Systems, Languages and Applications, pp. 201-214, ACM Press 1993.

....support for delegation based component interaction. Also, components to be composed by delegation depend on the specialization interface of their parent components. Therefore, advanced component interface specifications and approaches to the semantic fragile base class problem are required ([Lam93,SLMD96,MS97,Szy98,Wec97]) 7 Acknowledgements This paper benefited from many discussions with Pascal Costanza and Oliver Stiemerling and from many helpful comments of the anonymous ECOOP reviewers. ....

John Lamping. Typing the Specialization Interface. Proceedings OOPSLA '93, ACM SIGPLAN Notices, 28(10):201--214, 1993.

....include, for instance, addition and overriding of methods. Nevertheless, the semantics of mixins is still de ned such that inheritance with late binding of self is still ensured through mixin application. Several proposals have already been put forward to discipline the inheritance mech4 anism [17, 25], but it is still true that sub classing either based on explicit sub classing or relying on mixins addresses reuse by modifying the inherited code (even if such modi cations are limited to method overriding) rather than reusing it as a whole [26] The cumulative e ects of method overriding ....

John Lamping. Typing the specialization interface. In Andreas Paepcke, editor, Proceedings of the 8th Annual Conference on Object-Oriented Programming Systems, Languages and Applications, pages 201-214, Washington, DC, USA, 1993.

No context found.

J. Lamping. Typing the specialization interface. In Proceedings of OOPSLA, 1993.

No context found.

Lamping, J. - 1993. Typing the Specialization Interface. OOPSLA `93 Proceedings, pp. 201-214, ACM Press.

No context found.

John Lamping. Typing the Specialization Interface. In Proceedings of the Conference on Object-Oriented Programming, Systems, Languages, and Applications ACM SIGPLAN Notices 28(10), October 1993.

No context found.

John Lamping. Typing the specialization interface. ACM SIGPLAN Notices, 28(10):201--214, October 1993. OOPSLA '93 conference proceedings.

No context found.

J. Lamping. Typing the specialization interface. ACM SIGPLAN Notices, pages 201--214, 1993. OOPSLA'93.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC