William Harrison and Harold Ossher. Subject-Oriented Programming -- A Critique of Pure Objects. Proc. 1993 Conference on Object- Oriented Programming Systems, Languages, and Applications, September 1993.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....and access control lists are utilized to allow the owners of objects to control who can invoke methods on which objects. This effort differs from our approach, since it offers an instance level of control. Another effort allows different classes in an application to have different subjective views [6], which is similar to our approach of having different methods of the public interface available to different users based on their roles. All three efforts [6, 12, 13] like our own work, examine the realization of their security approaches via generated code. The main purpose of this paper is to ....

....since it offers an instance level of control. Another effort allows different classes in an application to have different subjective views [6] which is similar to our approach of having different methods of the public interface available to different users based on their roles. All three efforts [6, 12, 13], like our own work, examine the realization of their security approaches via generated code. The main purpose of this paper is to investigate URBS enforcement mechanisms for objectoriented systems, in general, and the ADAM environment, in particular. In Section 2, we review URBS and ADAM using a ....

W. Harrison and H. Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)", Proc. of 1993.

....capabilities, including, roles [16] In this work, new operations and data are possible for new roles; in our work, the class has a superset of operations data to which the roles require selected access. Another effort allows different classes in an application to have different subjective views [9], which is similar to our approach of having different methods of the public interface available to different users based on their roles. More recent work has focused on composing these subjective views with only scant mention of implementation support in C [14] Finally, an effort on role based ....

W. Harrison and H. Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)", Proc. of 1993.

....simple, an advantage of our approach. Another advantage is representation generality. By using equations, we can define and refine both source code and non code representations of tools etc. with exactly the same formalism. A predecessor to MDSOC is the work by Harrison and Ossher on subjectivity [10], which embodies a fundamental observation about software design: an object does not have a single interface, but rather has a large number of interfaces. The interface that is given to an object is subjective, that is, one that is specific to the task at hand. As an example, consider a book. ....

W. Harrison and H. Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)", OOPSLA 1993, 411-427.

....Flexibility is gained by vertical integration denoted by the playedBy construct binding a role class to a base class. It is a contribution of Object Teams to define this relation in a flexibly yet well defined way. 2. 3 Managing object schizophrenia Publications of subject oriented programming [4] have introduced the notion of object schizophrenia with respect to some common design patterns, where flexible modularity is achieved by splitting one entity into several objects using forwarding for communication between those atomic objects that in the initial design had been just one instance. ....

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In Proc. of OOPSLA'93. ACM, 1993.

....Flexibility is gained by vertical integration denoted by the playedBy construct binding a role class to a base class. It is a contribution of Object Teams to de ne this relation in a exibly yet well de ned way. 2. 3 Managing object schizophrenia Publications of subject oriented programming [4] have introduced the notion of object schizophrenia with respect to some common design patterns, where exible modularity is achieved by splitting one entity into several objects using forwarding for communication between those atomic objects that in the initial design had been just one instance. ....

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In Proc. of OOPSLA'93. ACM, 1993.

....scoping and or rename local variables to get unique names. More such issues exists. Mixing the implementations (the last possibility) requires knowledge of both the implementations i c and i d . In other methods like Aspect Oriented Programming [17] see also 4. 1) and Subject Oriented Programming [10] (see 4.2) this kind of mixing is impossible or very restricted. In fact they are more or less equal to the concatenation or skipping alternative, because code blocks are considered atomic. Code blocks don t have to be atomic entities beforehand, the black box can be opened up. Suppose i c is an ....

....Latest possible time of binding is in the current implementation of AspectJ compile time. In theory there is no limit why this couldn t be run time for AspectJ, beside the earlier described state problem (see 2.3) 4. 2 Subject Orientated Programming (SOP) Subject Orientated Programming (SOP) [10][34] introduces the concept of different points of view. The subjective view on an entity determines the way how the universe in which the entity lives looks like. The inheritance relationship of an entity is defined within this subjective view (universe) A subject is the complete subjective view ....

[Article contains additional citation context not shown here]

William Harrison and Harold Ossher. Subject-oriented programming: a critique of pure objects. In Proceedings of the eighth annual conference on Object-oriented programming systems, languages, and applications, pages 411--428. ACM Press, 1993. http://doi.acm.org/10.1145/165854. 165932

....that our interviewees could understand them and identify with the topic. Where applicable, we will provide explanations of terminology in the remainder of the paper. 2. 2 Selection of concerns The purpose of ASOC techniques such as Aspect Oriented Programming or Subject Oriented Programming [12][10] is to enable programmers to address concerns such as e.g. synchronization or logging separately and automate the integration of the separately developed concerns. Since interview time and the knowledge of our interviewees about ASOC were limited, we selected a handful of well understood concerns ....

....the concern synchronization from the rest of the system, changes in the synchronization code will not affect the rest of the system. Examples of approaches that aim to improve separation of concerns are Composition Filters [1] Aspect Oriented Programming [12] Subject Oriented Programming [10] and Multi Dimensional Separation of Concerns [23] An issue with these approaches is that these are mostly implementation level approaches. While some approaches for using ASOC on the detailed design level have been suggested (e.g. 4] good design level equivalents of the concepts used in the ....

W. Harrison, H. Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)", Proceedings of OOPSLA `93, pp 411-428.

.... distinguishing programs within a family of related programs (e.g. a product line) 13] There are many implementations of feature refinements, each with different names, capabilities, and limitations: lay ers [2] feature modules [17] meta classes [10] collabora tions [23] 24] subjects [14], aspects [18] and concerns [27] More general than traditional modules that encapsulate sets of complete classes, a feature refinement usually encapsulares fragments of multiple classes. Figure 1 depicts three classes, c1 c3. Refinement rl cross cuts these classes, i.e. it encapsulates ....

W. Harrison and H. Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)", OOPSLA 1993, 411-427.

....in another because their interfaces are different, even though both applications may deal with what is fundamentally the same object. The principle of subjectivity asserts that no single interface can adequately describe any object; objects are described by a family of related interfaces [HO93, OH92, OKH 95] The appropriate interface for an object is applicationdependent (or subjective) Subjectivity arose from the need for simplifying programming abstractions e.g. defining views that emphasize relevant aspects of objects and that hide irrelevant details. Ossher and Harrison ....

....defining views that emphasize relevant aspects of objects and that hide irrelevant details. Ossher and Harrison took an important step further by recognizing that application specific views of inheritance hierarchies can be produced automatically by composing different subjects [HO93] Subjects encapsulate a primitive aspect or 31 view of a hierarchy, whose implementation requires a set of additions (e.g. new data and method members) to one or more classes of the hierarchy. Collaboration based designs and mixin layers are analogous to subjectivity and subjects. ....

William Harrison, and Harold Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)", OOPSLA 1993, 411-428.

....for modules that are larger than classes have emerged. Besides components as understood in the context of standard component models such as CCM and EJB, which are out of the scope of this paper, several other module proposals have been made for supporting the so called collaboration based design [5, 23, 19, 3, 20, 14, 4, 17]. Approaches of this kind build on the insight that the design of object oriented applications can be organized along two dimensions: structural abstractions (object types) and collaborations in which these abstractions are involved (see Fig. 1 for illustration) In general, an abstraction is ....

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In Proc. of OOPSLA'93, pages 411--428. ACM, 1993.

....emerged over the last decade. In addition to components as defined by standard component models such as the CORBA Component Model and Enterprise Java Beans, which are beyond the scope of this paper, several other module proposals have been made for supporting so called collaboration based design [4, 19, 16, 2, 17, 12, 3, 15]. Approaches of this kind build on the insight that the design of object oriented applications can be organized in two dimensions: using structural abstractions (object types) and collaborations in which these abstractions are involved (see Fig. 1) Generally speaking, an object is involved in ....

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In Proc. of OOPSLA'93, pages 411--428. ACM, 1993.

....language to provide means (like super for inherited methods) for accessing these methods within overriding or advising methods. For a more in depth discussion of related work we refer to [1] Much of what has been said there could only be repeated here. This concerns the discussion of SOP[2] and especially of OORAM[10] 4. SUMMARY We have presented an extension to the UML called UFA (UML for Aspects) which treats aspect composition at the level of packages. Aspects as well as their bindings make use of a specialization relationship between packages. Details of binding can be given ....

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In Proc. of OOPSLA'93, pages 411-428. ACM, 1993.

....language to provide means (like super for inherited methods) for accessing these methods within overriding or advising methods. For a more in depth discussion of related work we refer to [1] Much of what has been said there could only be repeated here. This concerns the discussion of SOP[2] and especially of OORAM[10] 4. SUMMARY We have presented an extension to the UML called UFA (UML for Aspects) which treats aspect composition at the level of packages. Aspects as well as their bindings make use of a specialization relationship between packages. Details of binding can be given ....

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In Proc. of OOPSLA '93, pages 411--428. ACM, 1993.

....is useful to validate the design of a composition pattern, and its impact on a base design, it is also possible to maintain the separation to the code phase, using an appropriate implementation model. Conceptually, subject oriented design evolved from the work on subject oriented programming [8,14]. Efforts into the development of a tool to support multi dimensional separation of concerns (as evolved from subject oriented programming) are currently centred around Hyper J [18] Though the precise mappings from constructs in composition patterns to constructs in Hyper J has not yet been done, ....

....behaviour makes the design phase more relevant to this kind of programming, lending the standard benefits of software design to the approach. 6 RELATED WORK Conceptually, the subject oriented design and composition patterns model has evolved from the work on subjectoriented programming [8, 14]. Different subjects may be designed (or programmed) to support separate requirements, be they functional (and conceptually overlapping) or cross cutting requirements. Subsequent composition of separated subjects is specified with composition relationships (or defined by composition rules in ....

W. Harrison and H. Ossher. "Subject-Oriented Programming (a critique of pure objects)". In Proc. of OOPSLA, pp. 411--428, 1993.

....operators are comparable to component based weaver, i.e. a weaver that is no longer a black box, but is also composable out of components, and can be, in a sense, re composed for every combination of aspects and components, further improving the reuse. Subject oriented programming (SOP) [83], an example of systems with composition operators, provide composition operators for classes, such as merge (merges two views of a class) equate (merges two definition of classes into one) etc. SOP is a powerful technique for compositional system development, since it provides CHAPTER 3. ....

H. Ossher and P. Tarr. Subject-oriented programming: a critique of pure objects. In Proceedings of the eighth annual conference on object-oriented programming systems, languages, and applications, pages 411--428, Washington, USA, September 26 - October 1 1993. ACM Press.

....Hyper J, we decided to separate the concerns in this example by using concern specific hierarchies. Taking this approach involved creating concern specific versions of the classes of interest. Our intent was to be able to create independent hierarchies in the style of subject oriented programming [5] that could then be composed. Independent concernspecific hierarchies may make it easier to build and manage different pieces of a system. Figure 5b depicts the two hierarchies created. The Kernel hierarchy included versions of the Handler and StatusWindow classes. Two other pieces of structure ....

W. Harrison and H. Ossher. Subject-oriented programming: A critique of pure objects. In Proc. of OOPSLA, pages 411--428, 1993.

....[5] We first illustrate the design of the Observer pattern using the composition pattern approach, and then map that design to the appropriate code. 1 INTRODUCTION Requirements that have a crosscutting impact on software elements present well documented difficulties for software development [3, 4, 5, 7]. The difficulties impact comprehensibility, traceability, evolvability and reusability of software artefacts. These problems are present throughout the development lifecycle, and must therefore be addressed across the lifecycle. Composition patterns (CPs) present a means for separating the ....

....files being composed, and the pieces of Java within those files that map to different concerns of interest. A hypermodule file describes how integration between concerns of interest should be done. CPs, with their inherent merge semantics, evolved from ideas within subject oriented programming [3, 5], as did the implementation of Hyper J. As such, at a high level, there is a more direct map from CPs to the inputs of Hyper J than was demonstrated with AspectJ. 1 The internals of the Observer CP, and the Library base design may be described using hyperspace and concern mapping files, while ....

W. Harrison and H. Ossher. "Subject-Oriented Programming (a critique of pure objects)." In Proc. OOPSLA, pp. 411--428, 1993.

....way to represent a number of data types that each address another concern within the same application domain. Obviously other technologies that takes separation of concerns to a higher level could be used. Data types could for instance be represented using a subject (Subject oriented programming: [5]) or a hyperslice (Multi dimensional separation of concerns with the hyperspace approach: 6] One could also decide to implement the component specific data structure handling on a meta level instead of using aspects. The meta level would offer us a generic execution model for the component ....

William Harrison and Harold Ossher. "Subject-oriented programming (a critique of pure objects)." In Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applications (OOPSLA), September 1993.

.... Examples of such system include AspectJ, which allows (among other things) quantifying over both the calling and accepting calls in subprograms [13] and Subject Oriented Programming, whose composition rules allow quantifying over elements such as the interpretation of variables within modules [10]. A given AOP system will present a quantification language that may be as simple as just allowing aspect decoration of subprogram calls, or complex enough to represent pattern matching on the abstract syntax tree of the program. Understood this way, a clear box AOP system could allow static ....

Harrison, W., and Ossher, H., Subject-Oriented Programming -- a critique of pure objects. Proceedings of 1993 Conference on Object-Oriented Programming Systems, Languages, and Applications, Washington, September 1993, pp. 411--428.

.... based designs [23 8 27 32] reflective architectures [13 10 14 15] and more recent approaches such as aspect oriented programming [11] programming with reusable collaborations [16] and the multidimensional separation of concerns model [30] The main message of this post objective era [5] is that (a) existing software formalisms support separation of concerns only along a predominant dimension (e.g. the data type axis in object oriented languages as opposed to functions in procedural programming) while neglecting other dimensions, b) focusing on only one dimension causes the ....

....specifies some additional semantics to be inserted into the base behavior at the level of classes, methods, or even blocks, such as catch. Q3: Explicit integration: Is concern integration defined separately or is it part of the concern definitions The models of subject oriented programming (SOP [5]) and Pluggable Composite Adapters (PCA [17] allow to define integration in separate units whereas, e.g. in AspectJ [20] concerns and their integration are defined in the same place. Q4: Binding time: Are concerns bound at compile, link or load time or can binding be delayed until run time ....

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In Proc. of OOPSLA '93, pages 411--428. ACM, 1993.

....problems of consistency among program development tools and surveys approaches including use of files, databases, and views as developed by Garlan. Hailpern and Ossher [25] describe views as subsets of methods of a class, to restrict certain methods to particular clients. Harrison and Ossher [26] argue that OOP is too restrictive for applications that need their own views of objects; they propose subjects that are analogous to class hierarchies. 8.7 Data Translation IDL (Interface Description Language) 36] translates representations, possibly with structure sharing, for exchange of ....

W. Harrison and H. Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)," Proc. OOPSLA-93, ACM SIGPLAN Notices, vol. 28, no. 10, pp. 411-428, Oct. 1993.

....should be identified. This can be done from scratch by identifying the agents in an application and their collaborations. Alternatively, a role model catalog can be used; this provides commonly occurring agent role models. A role model catalog resembles a set of patterns or a pattern language [8, 12, 13], and role model catalogs are being used at BT for downstreaming agent technology. The role model catalog developed at BT includes approximately 60 role models, including those from agent enhanced workflow, flexible manufacturing, electronic E. A. Kendall, Role Models for Analysis, Design, and ....

Harrison, W., H. Ossher, "Subject- Oriented Programming (a critique of pure objects)," in Proceedings of the Conference on Object Oriented Programming: Systems, Languages, and Applications, Washington, D. C. September, 1993. pp. 411 - 428.

....similar to the adapters of our framework. In contrast to our system, their model does not support inheritance which is essential to our system. Subject Oriented Programming. Subject Oriented Programming (SOP) focuses on the development and the evolution of suites of cooperating applications [HO93]. Applications can show a highly varying granularity. Hence, we can consider such applications components. SOP s goal is that components can be independently developed and evolved, combined to suites, and that these suites can be dynamically changed, for example by adding new components or ....

....at large, such as is seen by a particular application or tool. Subjects define an subjective view onto existing objects or collections of objects. A subject . corresponds to a traditional (tough usually incomplete) class hierarchy, describing the interfaces and classes known to this subject [HO93]. Subjects can be combined in order to form compositions. Each composition defines a composition rule specifying the combination of the subjects partial class hierarchies. Regarding component adaptation, SOP is highly powerful. The component and its adapters might be considered subjects. Subject ....

Harrison W. and Ossher H. "Subject-Oriented Programming (A Critique of Pure Objects)". In OOPSLA'93 Conference Proceedings. ACM Press, NewYork, October 1993.

.... based designs [39 18 46 51] reflective architectures [25 21 26 27] and more recent approaches such as aspect oriented programming [22] programming with reusable collaborations [28] and the multidimensional separation of concerns model [49] The main message of this post objective era [15] is that (a) existing software formalisms support separation of concerns only along a predominant dimension (e.g. the data type axis in object oriented languages as opposed to functions in procedural programming) while neglecting other dimensions, b) Pre print To appear in proceedings ....

....distribution concerns. In most other approaches the actual implementation of concerns relies mostly on standard object oriented notions. Q2: Explicit integration: Is concern integration defined separately or is it part of the concern definitions The models of subject oriented programming (SOP [15]) and Pluggable Composite Adapters (PCA [29] allow to define integration in separate units whereas, e.g. in AspectJ [35] concerns and their integration are defined in the same place. Q3: Binding time: Are concerns bound at compile, link or load time or can binding be delayed until run time ....

W. Harrison and H. Ossher. Subject-Oriented Programming: a Critique of Pure Objects. In Proceedings of ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA '93), Sigplan Notices 28(10), pp. 411--428, 1993. 1, 2

.... based designs [39, 18, 46, 51] re ective architectures [25, 21, 26, 27] and more recent approaches such as aspect oriented programming [22] programming with reusable collaborations [28] and the multidimensional separation of concerns model [49] The main message of this post objective era [15] is that (a) existing software formalisms support separation of concerns only along a predominant dimension (e.g. the data type axis in object oriented languages as opposed to functions in procedural programming) while neglecting other dimensions, b) Pre print To appear in proceedings of ....

....and distribution concerns. In most other approaches the actual implementation of concerns relies mostly on standard object oriented notions. Q2: Explicit integration: Is concern integration de ned separately or is it part of the concern de nitions The models of subject oriented programming (SOP [15]) and Pluggable Composite Adapters (PCA [29] allow to de ne integration in separate units whereas, e.g. in AspectJ [35] concerns and their integration are de ned in the same place. Q3: Binding time: Are concerns bound at compile, link or load time or can binding be delayed until run time The ....

W. Harrison and H. Ossher. Subject-Oriented Programming: a Critique of Pure Objects. In Proceedings of ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA '93), Sigplan Notices 28(10), pp. 411-428, 1993. 18

....guards for threads that are trying to push an element onto a full stack, or to pop an element from an empty stack. The push( and pop( methods must be made to use these locks appropriately. A key idea of aspect oriented programming [18] composition filters [1] subjectoriented programming [16], and other work in the advanced separation of concerns area is that manually mixing concerns, like synchronization code, into the source implementation of pop( and push( of the original stack is a bad idea it results in tangled code, which is hard to understand and to maintain, as shown in ....

....are often wrong and much of the complexity turns out to be unnecessary. A solution to this problem is the use of a composition mechanism, which, unlike inheritance, facilitates the extension of classes without invalidating client code. This permits noninvasive changes without pre planning [16][22] 25] Requirement 5 Approaches to advanced separation of concerns should provide composition mechanisms that permit the addition of new aspects or concerns to existing code non invasively, without invalidating existing clients, and without preplanning, to whatever extent possible. At some ....

William Harrison and Harold Ossher. "Subject-Oriented Programming (A Critique of Pure Objects)." In Proceedings of OOPSLA'93, September, 1993, pages 411-428.

No context found.

William Harrison and Harold Ossher, "Subject-oriented programming (a critique of pure objects)." In Proceedings of the Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA '93), (Washington, D.C.), ACM, September 1993. 12

No context found.

William Harrison and Harold Ossher. "Subjectoriented programming (a critique of pure objects)." In Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applications (OOPSLA), September 1993.

No context found.

William Harrison and Harold Ossher. "Subjectoriented programming (a critique of pure objects)." In Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applications (OOPSLA), September 1993.

....are groups. The filtered objects are aspects or full aspects. With composition filters, group behavior is obtained only by directing messages to the group. It has the compose two way variant of the instance composition operator. 6. 2 Subject Oriented Programming Subject Oriented programming [3] introduced the notion that objects in a group can have the same identity and that creation of an instance of one of the member classes causes creation of the group. The member is a class facet, although the creation need not be delegated to all members. As discussed above, this implies that ....

Harrison, W., and Ossher, H. Subject-Oriented Programming - A Critique of Pure Objects. In Proceedings of the 1993.

....we discuss an approach to design that addresses this misalignment problem and, in so doing addresses the other problems noted earlier that have impeded the successful use of designs. The approach is based on the flexible decomposition and composition provided by subject oriented programming [HO93, OK 96] This approach permits standard design models to be decomposed into smaller, potentially overlapping, units, called design subjects. Each design subject encapsulates a single, coherent piece of functionality (e.g. one or more features or components, often cutting across multiple ....

....are appropriate under different circumstances, so that homogeneity, while appealing, is likely to be inadequate. Our approach, which we call subject oriented design, is an outgrowth of the work on subject oriented programming, which addressed misalignment and related problems at the code level [HO93, OK 96] Like subject oriented programming, subject oriented design supports decomposition of objectoriented software into modules, called subjects, that cut across classes, and integration of subjects to form complete designs. A subject oriented design is an object oriented design model that is ....

[Article contains additional citation context not shown here]

W. Harrison, H. Ossher, "Subject-Oriented Programming (a critique of pure objects)" In Proc. ObjectOriented Programming Systems, Languages and Applications (OOPSLA) 1993

....domain are multiple views [7] or separation of requirements by feature [5] Much work also exists within the analysis and design domain, where role modelling [10] Catalysis [2] and contracts [4] are just some examples. Within the implementation domain, work on subject oriented programming [3,8] and aspect oriented programming [6] has identified difficulties associated with code tangling in software development. Each has provided solutions for separating code that affects many units of functionality in the system (i.e. cross cutting code) with corresponding composition techniques to ....

....aspects like persistence, error detection handling, logging, tracing, caching, synchronisation etc. Our work on subjectoriented design is centred on this approach, and is an outgrowth of the work on subjectoriented programming, which addressed misalignment and related problems at the code level [3,8]. Like subject oriented programming, subject oriented design supports decomposition of object oriented software into modules, called subjects, that cut across classes, and integration of subjects to form complete designs. In this position paper, we focus on the design phase, since design models ....

Harrison, W., Ossher, H., "Subject-Oriented Programming (a critique of pure objects)" In Proc. OOPSLA'93

No context found.

William Harrison and Harold Ossher. Subject-Oriented Programming -- A Critique of Pure Objects. Proc. 1993 Conference on Object- Oriented Programming Systems, Languages, and Applications, September 1993.

No context found.

W. Harrison, H. Ossher, Subject-Oriented Programming - A Critique of Pure Objects, Proceedings of 1993.

No context found.

William Harrison and Harold Ossher. Subject-oriented programming: a critique of pure objects. In Proceedings of the eighth annual conference on Object-oriented programming systems, languages, and applications, pages 411--428. ACM Press, 1993.

No context found.

William Harrison and Harold Ossher. Subject-oriented programming---a critique of pure objects. In Proc. 1993.

No context found.

W. Harrison and H. Ossher, "Subject-oriented programming (a critique of pure objects)," in OOPSLA '93, 1993.

No context found.

W. Harrison and H. Ossher, "Subject-oriented programming (a critique of pure objects)," in OOPSLA'93, 1993.

No context found.

Harrison, W., and Ossher, H. Subject-Oriented Programming - A Critique of Pure Objects. In Proceedings of the 1993.

No context found.

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages & Applications, pages 411--428, 1993.

No context found.

Harrison, W., Ossher, H., "Subject-Oriented Programming (A Critique of Pure Objects)", Proceedings of OOPSLA 1993.

No context found.

Harrison, W., and Ossher, H., (1993) Subject-oriented programming: a critique of pure objects, in Proceedings of OOPSLA'93 ; Washington D.C., pp. 411-428.

No context found.

W. Harrison and H. Ossher. Subject-oriented programming: a critique of pure objects. In Proc. of OOPSLA'93, pages 411--428. ACM, 1993. 180, 241, 254, 255

No context found.

Harrison, W., Ossher, H., "Subject-Oriented Programming (A Critique of Pure Objects)", Proceedings of OOPSLA 1993, ACM SIGPLAN Notices, Vol. 28, No. 10, Oct.

No context found.

Harrison, W., Ossher, H., "Subject-Oriented Programming (A Critique of Pure Objects)", Proceedings of OOPSLA 1993.

No context found.

W. Harrison and H. Ossher, "Subject-oriented programming: a critique of pure objects," in Proc. of OOPSLA'93, pp. 411-428.

No context found.

W. Harrison, and H. Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)", Proc. OOPSLA '93. ACM SIGPLAN Notices 28 (10) 1993, 411-428.

No context found.

Harrison, W., H. Osher, "Subject- Oriented Programming (a critique of pure objects)," in Proceedings of the Conference on Object- oriented Programming: Systems, Languages, and Applications, Washington, D. C. September, 1993. pp. 411 - 428.

No context found.

Harrison, W. and H. Ossher. "Subject-Oriented Programming (A critique of Pure Objects)," Conference Proceedings, published as ACM SIGPLAN Notices, 28(10):411--428, October 1993.

No context found.

W. Harrison and H. Ossher, "Subject-Oriented Programming (A Critique of Pure Objects)", OOPSLA 1993.

First 50 documents  Next 50

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