Generic Classes and Methods: a Deeper Look Week 5- Part A

Total Page:16

File Type:pdf, Size:1020Kb

Generic Classes and Methods: a Deeper Look Week 5- Part A Generic Classes and Methods: A Deeper Look Week 5- part A Dr Mohammed Bahja [email protected] https://www.cs.bham.ac.uk/~bahjam/ Before we start Ø Attendance code of today Ø In-class test ( week 6 –Friday) Ø No WS 4 (you will start the project a week early) Ø Groups for group project. Lecture Objective To develop a thorough understanding of generic programming and how generic classes and methods can be used to provide simpler and elegant solutions Lecture Outline Ø Objective of generic programming Ø How implement generic classes and methods Ø The execution of generic methods Ø Raw Type and Backward Compatibility Ø Overloading Generic Methods Ø The relationship between generic types and inheritance Ø Wildcards in Methods That Accept Type Parameters Ø Wildcards Types Why Do You Get a Warning? Ø To understand the compile warning on line 6 & 7, you need to learn generics. The Warning? ArrayList list = new ArrayList(); list.add("Java Programming"); Compile-time type safety Ø Detect type mismatches at compile time—known as compile- time type safety. Ø Generic methods and generic classes provide the means to create type safe general models. Overloaded methods Ø Overloaded methods are often used to perform similar operations on different types of data. Ø We can use Overloaded methods to print -for example- arrays of different types. But how many methods you need to create ? Overloaded methods (Cont’d) Ø Method for each data type Implementation and Compile-Time Translation Ø If the operations performed by several overloaded methods are identical for each argument type, the overloaded methods can be more conveniently coded using a generic method. Ø You can write a single generic method declaration that can be called with arguments of different types them the compiler handles each method call appropriately. What is Generics? Ø Generic programming: creation of programming constructs that can be used with many different types. Ø In Java, achieved with inheritance or with type variables Ø The type variable denotes the element type public class ArrayList<E> // could use "ElementType" instead of E { public ArrayList() { . } public void add(E element) { . } . } Ø You can define a class or a method with generic types that can be substituted using concrete types by the compiler. Why Generics? Ø The key benefit of generics is to enable errors to be detected at compile time rather than at runtime. Ø A generic class or method permits you to specify allowable types of objects that the class or method may work with. Ø If you attempt to use the class or method with an incompatible object, a compile error occurs. Type Variables Ø Can be instantiated with class or interface typesArrayList<BankAccount> ArrayList<Measurable> Ø Cannot use a primitive type as a type variableArrayList<double> // Wrong! Ø Use corresponding wrapper class insteadArrayList<Double> Safer and easier to read package java.lang; package java.lang; public interface Comparable { public interface Comparable<T> { public int compareTo(Object o) public int compareTo(T o) } } (a) Prior to JDK 1.5 (b) JDK 1.5 Comparable c = new Date(); Comparable<Date> c = new Date(); System.out.println(c.compareTo("red")); System.out.println(c.compareTo("red")); (a) Prior to JDK 1.5 (b) JDK 1.5 Runtime error Compile error Safer and easier to read (Cont’d) Ø Impossible to add a String into an ArrayList<BankAccount> Ø Can add a String into a LinkedList intended to hold bank accounts ArrayList<BankAccount> accounts1 = new ArrayList<BankAccount>(); LinkedList accounts2 = new LinkedList(); // Should hold BankAccount objects accounts1.add("my savings"); // Compile-time error accounts2.add("my savings"); // Not detected at compile time . BankAccount account = (BankAccount) accounts2.getFirst(); // Run-time error Generic ArrayList in JDK 1.5 No Casting Needed ArrayList<Double> list = new ArrayList<>(); list.add(5.5); // 5.5 is automatically converted to new Double(5.5) list.add(3.0); // 3.0 is automatically converted to new Double(3.0) Double doubleObject = list.get(0); // No casting is needed double d = list.get(1); // Automatically converted to double Raw Type and Backward Compatibility Ø When generics were introduced into Java, several classes were updated to use generics. Ø Raw types refer to using a generic type without specifying a type parameter. For example, List is a raw type, while List<String> is a parameterized type. Ø Using these class as a raw type allowed legacy code to still compile (backwards compatibility). Ø Although using raw types is still possible, they should be avoided. (I guess by now you know why ? ) Raw Type is Unsafe Ø What is the output of the code below if we call Max.max("Welcome", 23); ? // Max.java: Find a maximum object public class Max { /** Return the maximum between two objects */ public static Comparable max(Comparable o1, Comparable o2) { if (o1.compareTo(o2) > 0) return o1; else return o2; } } Make it Safe Ø What would you change to make it safe ? // Max1.java: Find a maximum object public class Max1 { /** Return the maximum between two objects */ public static <E extends Comparable<E>> E max(E o1, E o2) { if (o1.compareTo(o2) > 0) return o1; else return o2; } } Generic Classes Ø The concept of a data structure, such as a stack, can be understood independently of the element type it manipulates. Ø Generic classes provide a means for describing the concept of a stack (or any other class) in a type-independent manner. Ø These classes are known as parameterized classes or parameterized types because they accept one or more type parameters. public class Stack <E> { .... } Generic Methods Ø Generic method: method with a type variable Ø Can be defined inside ordinary and generic classes Ø All generic method declarations have a type-parameter section (< T > in this example) delimited by angle brackets that precedes the method’s return type. Ø Cannot replace type variables with primitive types e.g.: cannot use the generic print method to print an array of type int[] Good practice Overloading Generic Methods Ø A generic method may be overloaded like any other method. Ø A class can provide two or more generic methods that specify the same method name but different method parameters. Ø A generic method can also be overloaded by nongeneric methods. Ø When the compiler encounters a method call, it searches for the method declaration that best matches the method name and the argument types specified in the call—an error occurs if two or more overloaded methods both could be considered best matches. Common Error Wildcards in Methods That Accept Type Parameters Ø Suppose that you’d like to implement a generic method sum that totals the numbers in a List. Ø You’d begin by inserting the numbers in the collection. Ø The numbers would be autoboxed as objects of the type-wrapper classes— any int value would be autoboxed as an Integer object, and any double value would be autoboxed as a Double object. Ø We’d like to be able to total all the numbers in the List regardless of their type. Ø For this reason, we’ll declare the List with the type argument Number, which is the superclass of both Integer and Double. Ø In addition, method sum will receive a parameter of type List <Number> and total its elements. Types inheritance Ø In the previous example, it’s not valid to have List <Double> numberList= new ArrayList<> (); Ø You can not inherited just a part of a type Object List <Object> Object Number List <Number> Double List <Double> List <Number> List <Double> True False True Upper Bounded Wildcards Ø Given that method sum can total the elements of a List of Numbers, you might expect that the method would also work for Lists that contain elements of only one numeric type, such as List<Integer>. Ø Modified class TotalNumbers to create a List of Integers and pass it to method sum. Ø When we compile the program, the compiler issues the following error message: Ø sum(java.util.List<java.lang.Number>) in TotalNumbersErrors cannot be applied to (java.util.List<java.lang.Integer>) Ø Although Number is the superclass of Integer, the compiler doesn’t consider the parameterized type List<Number> to be a superclass of List<Integer>. Upper Bounded Wildcards (Cont’d) Ø To create a more flexible version of the sum method that can total the elements of any List containing elements of any subclass of Number we use wildcard-type arguments. Ø Wildcards enable you to specify method parameters, return values, variables or fields, and so on, that act as supertypes or subtypes of parameterized types. Ø Imethod sum’s parameter can be declared with the type: List<? extends Number> Ø A wildcard-type argument is denoted by a question mark (?), which by itself represents an “unknown type.” Ø In this case, the wildcard extends class Number, which means that the wildcard has an upper bound of Number. Ø Thus, the unknown-type argument must be either Number or a subclass of Number. Upper Bounded Wildcards(Cont’d) Ø Because the wildcard (?) in the method’s header does not specify a type-parameter name, you cannot use it as a type name throughout the method’s body Ø You could, however, declare method sum as follows: public static <T extends Number> double sum(List<T> list) Ø Allows the method to receive an List that contains elements of any Number subclass. Ø You could then use the type parameter T throughout the method body. Ø If the wildcard is specified without an upper bound, then only the methods of type ObJect can be invoKed on values of the wildcard type.
Recommended publications
  • Safety Properties Liveness Properties
    Computer security Goal: prevent bad things from happening PLDI’06 Tutorial T1: Clients not paying for services Enforcing and Expressing Security Critical service unavailable with Programming Languages Confidential information leaked Important information damaged System used to violate laws (e.g., copyright) Andrew Myers Conventional security mechanisms aren’t Cornell University up to the challenge http://www.cs.cornell.edu/andru PLDI Tutorial: Enforcing and Expressing Security with Programming Languages - Andrew Myers 2 Harder & more important Language-based security In the ’70s, computing systems were isolated. Conventional security: program is black box software updates done infrequently by an experienced Encryption administrator. Firewalls you trusted the (few) programs you ran. System calls/privileged mode physical access was required. Process-level privilege and permissions-based access control crashes and outages didn’t cost billions. The Internet has changed all of this. Prevents addressing important security issues: Downloaded and mobile code we depend upon the infrastructure for everyday services you have no idea what programs do. Buffer overruns and other safety problems software is constantly updated – sometimes without your knowledge Extensible systems or consent. Application-level security policies a hacker in the Philippines is as close as your neighbor. System-level security validation everything is executable (e.g., web pages, email). Languages and compilers to the rescue! PLDI Tutorial: Enforcing
    [Show full text]
  • Abstract Data Types
    Chapter 2 Abstract Data Types The second idea at the core of computer science, along with algorithms, is data. In a modern computer, data consists fundamentally of binary bits, but meaningful data is organized into primitive data types such as integer, real, and boolean and into more complex data structures such as arrays and binary trees. These data types and data structures always come along with associated operations that can be done on the data. For example, the 32-bit int data type is defined both by the fact that a value of type int consists of 32 binary bits but also by the fact that two int values can be added, subtracted, multiplied, compared, and so on. An array is defined both by the fact that it is a sequence of data items of the same basic type, but also by the fact that it is possible to directly access each of the positions in the list based on its numerical index. So the idea of a data type includes a specification of the possible values of that type together with the operations that can be performed on those values. An algorithm is an abstract idea, and a program is an implementation of an algorithm. Similarly, it is useful to be able to work with the abstract idea behind a data type or data structure, without getting bogged down in the implementation details. The abstraction in this case is called an \abstract data type." An abstract data type specifies the values of the type, but not how those values are represented as collections of bits, and it specifies operations on those values in terms of their inputs, outputs, and effects rather than as particular algorithms or program code.
    [Show full text]
  • Cyclone: a Type-Safe Dialect of C∗
    Cyclone: A Type-Safe Dialect of C∗ Dan Grossman Michael Hicks Trevor Jim Greg Morrisett If any bug has achieved celebrity status, it is the • In C, an array of structs will be laid out contigu- buffer overflow. It made front-page news as early ously in memory, which is good for cache locality. as 1987, as the enabler of the Morris worm, the first In Java, the decision of how to lay out an array worm to spread through the Internet. In recent years, of objects is made by the compiler, and probably attacks exploiting buffer overflows have become more has indirections. frequent, and more virulent. This year, for exam- ple, the Witty worm was released to the wild less • C has data types that match hardware data than 48 hours after a buffer overflow vulnerability types and operations. Java abstracts from the was publicly announced; in 45 minutes, it infected hardware (“write once, run anywhere”). the entire world-wide population of 12,000 machines running the vulnerable programs. • C has manual memory management, whereas Notably, buffer overflows are a problem only for the Java has garbage collection. Garbage collec- C and C++ languages—Java and other “safe” lan- tion is safe and convenient, but places little con- guages have built-in protection against them. More- trol over performance in the hands of the pro- over, buffer overflows appear in C programs written grammer, and indeed encourages an allocation- by expert programmers who are security concious— intensive style. programs such as OpenSSH, Kerberos, and the com- In short, C programmers can see the costs of their mercial intrusion detection programs that were the programs simply by looking at them, and they can target of Witty.
    [Show full text]
  • Cs164: Introduction to Programming Languages and Compilers
    Lecture 19 Flow Analysis flow analysis in prolog; applications of flow analysis Ras Bodik Hack Your Language! CS164: Introduction to Programming Ali and Mangpo Languages and Compilers, Spring 2013 UC Berkeley 1 Today Static program analysis what it computes and how are its results used Points-to analysis analysis for understanding flow of pointer values Andersen’s algorithm approximation of programs: how and why Andersen’s algorithm in Prolog points-to analysis expressed via just four deduction rules Andersen’s algorithm via CYK parsing (optional) expressed as CYK parsing of a graph representing the pgm Static Analysis of Programs definition and motivation 3 Static program analysis Computes program properties used by a range of clients: compiler optimizers, static debuggers, security audit tools, IDEs, … Static analysis == at compile time – that is, prior to seeing the actual input ==> analysis answer must be correct for all possible inputs Sample program properties: does variable x has a constant value (for all inputs)? does foo() return a table (whenever called, on all inputs)? 4 Client 1: Program Optimization Optimize program by finding constant subexpressions Ex: replace x[i] with x[1] if we know that i is always 1. This optimizations saves the address computation. This analysis is called constant propagation i = 2 … i = i+2 … if (…) { …} … x[i] = x[i-1] 5 Client 2: Find security vulnerabilities One specific analysis: find broken sanitization In a web server program, as whether a value can flow from POST (untrusted source) to the SQL interpreter (trusted sink) without passing through the cgi.escape() sanitizer? This is taint analysis.
    [Show full text]
  • 5. Data Types
    IEEE FOR THE FUNCTIONAL VERIFICATION LANGUAGE e Std 1647-2011 5. Data types The e language has a number of predefined data types, including the integer and Boolean scalar types common to most programming languages. In addition, new scalar data types (enumerated types) that are appropriate for programming, modeling hardware, and interfacing with hardware simulators can be created. The e language also provides a powerful mechanism for defining OO hierarchical data structures (structs) and ordered collections of elements of the same type (lists). The following subclauses provide a basic explanation of e data types. 5.1 e data types Most e expressions have an explicit data type, as follows: — Scalar types — Scalar subtypes — Enumerated scalar types — Casting of enumerated types in comparisons — Struct types — Struct subtypes — Referencing fields in when constructs — List types — The set type — The string type — The real type — The external_pointer type — The “untyped” pseudo type Certain expressions, such as HDL objects, have no explicit data type. See 5.2 for information on how these expressions are handled. 5.1.1 Scalar types Scalar types in e are one of the following: numeric, Boolean, or enumerated. Table 17 shows the predefined numeric and Boolean types. Both signed and unsigned integers can be of any size and, thus, of any range. See 5.1.2 for information on how to specify the size and range of a scalar field or variable explicitly. See also Clause 4. 5.1.2 Scalar subtypes A scalar subtype can be named and created by using a scalar modifier to specify the range or bit width of a scalar type.
    [Show full text]
  • Lecture 2: Variables and Primitive Data Types
    Lecture 2: Variables and Primitive Data Types MIT-AITI Kenya 2005 1 In this lecture, you will learn… • What a variable is – Types of variables – Naming of variables – Variable assignment • What a primitive data type is • Other data types (ex. String) MIT-Africa Internet Technology Initiative 2 ©2005 What is a Variable? • In basic algebra, variables are symbols that can represent values in formulas. • For example the variable x in the formula f(x)=x2+2 can represent any number value. • Similarly, variables in computer program are symbols for arbitrary data. MIT-Africa Internet Technology Initiative 3 ©2005 A Variable Analogy • Think of variables as an empty box that you can put values in. • We can label the box with a name like “Box X” and re-use it many times. • Can perform tasks on the box without caring about what’s inside: – “Move Box X to Shelf A” – “Put item Z in box” – “Open Box X” – “Remove contents from Box X” MIT-Africa Internet Technology Initiative 4 ©2005 Variables Types in Java • Variables in Java have a type. • The type defines what kinds of values a variable is allowed to store. • Think of a variable’s type as the size or shape of the empty box. • The variable x in f(x)=x2+2 is implicitly a number. • If x is a symbol representing the word “Fish”, the formula doesn’t make sense. MIT-Africa Internet Technology Initiative 5 ©2005 Java Types • Integer Types: – int: Most numbers you’ll deal with. – long: Big integers; science, finance, computing. – short: Small integers.
    [Show full text]
  • Csci 658-01: Software Language Engineering Python 3 Reflexive
    CSci 658-01: Software Language Engineering Python 3 Reflexive Metaprogramming Chapter 3 H. Conrad Cunningham 4 May 2018 Contents 3 Decorators and Metaclasses 2 3.1 Basic Function-Level Debugging . .2 3.1.1 Motivating example . .2 3.1.2 Abstraction Principle, staying DRY . .3 3.1.3 Function decorators . .3 3.1.4 Constructing a debug decorator . .4 3.1.5 Using the debug decorator . .6 3.1.6 Case study review . .7 3.1.7 Variations . .7 3.1.7.1 Logging . .7 3.1.7.2 Optional disable . .8 3.2 Extended Function-Level Debugging . .8 3.2.1 Motivating example . .8 3.2.2 Decorators with arguments . .9 3.2.3 Prefix decorator . .9 3.2.4 Reformulated prefix decorator . 10 3.3 Class-Level Debugging . 12 3.3.1 Motivating example . 12 3.3.2 Class-level debugger . 12 3.3.3 Variation: Attribute access debugging . 14 3.4 Class Hierarchy Debugging . 16 3.4.1 Motivating example . 16 3.4.2 Review of objects and types . 17 3.4.3 Class definition process . 18 3.4.4 Changing the metaclass . 20 3.4.5 Debugging using a metaclass . 21 3.4.6 Why metaclasses? . 22 3.5 Chapter Summary . 23 1 3.6 Exercises . 23 3.7 Acknowledgements . 23 3.8 References . 24 3.9 Terms and Concepts . 24 Copyright (C) 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Note: This chapter adapts David Beazley’s debugly example presentation from his Python 3 Metaprogramming tutorial at PyCon’2013 [Beazley 2013a].
    [Show full text]
  • Metaclasses: Generative C++
    Metaclasses: Generative C++ Document Number: P0707 R3 Date: 2018-02-11 Reply-to: Herb Sutter ([email protected]) Audience: SG7, EWG Contents 1 Overview .............................................................................................................................................................2 2 Language: Metaclasses .......................................................................................................................................7 3 Library: Example metaclasses .......................................................................................................................... 18 4 Applying metaclasses: Qt moc and C++/WinRT .............................................................................................. 35 5 Alternatives for sourcedefinition transform syntax .................................................................................... 41 6 Alternatives for applying the transform .......................................................................................................... 43 7 FAQs ................................................................................................................................................................. 46 8 Revision history ............................................................................................................................................... 51 Major changes in R3: Switched to function-style declaration syntax per SG7 direction in Albuquerque (old: $class M new: constexpr void M(meta::type target,
    [Show full text]
  • Subtyping Recursive Types
    ACM Transactions on Programming Languages and Systems, 15(4), pp. 575-631, 1993. Subtyping Recursive Types Roberto M. Amadio1 Luca Cardelli CNRS-CRIN, Nancy DEC, Systems Research Center Abstract We investigate the interactions of subtyping and recursive types, in a simply typed λ-calculus. The two fundamental questions here are whether two (recursive) types are in the subtype relation, and whether a term has a type. To address the first question, we relate various definitions of type equivalence and subtyping that are induced by a model, an ordering on infinite trees, an algorithm, and a set of type rules. We show soundness and completeness between the rules, the algorithm, and the tree semantics. We also prove soundness and a restricted form of completeness for the model. To address the second question, we show that to every pair of types in the subtype relation we can associate a term whose denotation is the uniquely determined coercion map between the two types. Moreover, we derive an algorithm that, when given a term with implicit coercions, can infer its least type whenever possible. 1This author's work has been supported in part by Digital Equipment Corporation and in part by the Stanford-CNR Collaboration Project. Page 1 Contents 1. Introduction 1.1 Types 1.2 Subtypes 1.3 Equality of Recursive Types 1.4 Subtyping of Recursive Types 1.5 Algorithm outline 1.6 Formal development 2. A Simply Typed λ-calculus with Recursive Types 2.1 Types 2.2 Terms 2.3 Equations 3. Tree Ordering 3.1 Subtyping Non-recursive Types 3.2 Folding and Unfolding 3.3 Tree Expansion 3.4 Finite Approximations 4.
    [Show full text]
  • Subtyping, Declaratively an Exercise in Mixed Induction and Coinduction
    Subtyping, Declaratively An Exercise in Mixed Induction and Coinduction Nils Anders Danielsson and Thorsten Altenkirch University of Nottingham Abstract. It is natural to present subtyping for recursive types coin- ductively. However, Gapeyev, Levin and Pierce have noted that there is a problem with coinductive definitions of non-trivial transitive inference systems: they cannot be \declarative"|as opposed to \algorithmic" or syntax-directed|because coinductive inference systems with an explicit rule of transitivity are trivial. We propose a solution to this problem. By using mixed induction and coinduction we define an inference system for subtyping which combines the advantages of coinduction with the convenience of an explicit rule of transitivity. The definition uses coinduction for the structural rules, and induction for the rule of transitivity. We also discuss under what condi- tions this technique can be used when defining other inference systems. The developments presented in the paper have been mechanised using Agda, a dependently typed programming language and proof assistant. 1 Introduction Coinduction and corecursion are useful techniques for defining and reasoning about things which are potentially infinite, including streams and other (poten- tially) infinite data types (Coquand 1994; Gim´enez1996; Turner 2004), process congruences (Milner 1990), congruences for functional programs (Gordon 1999), closures (Milner and Tofte 1991), semantics for divergence of programs (Cousot and Cousot 1992; Hughes and Moran 1995; Leroy and Grall 2009; Nakata and Uustalu 2009), and subtyping relations for recursive types (Brandt and Henglein 1998; Gapeyev et al. 2002). However, the use of coinduction can lead to values which are \too infinite”. For instance, a non-trivial binary relation defined as a coinductive inference sys- tem cannot include the rule of transitivity, because a coinductive reading of transitivity would imply that every element is related to every other (to see this, build an infinite derivation consisting solely of uses of transitivity).
    [Show full text]
  • An Operational Semantics and Type Safety Proof for Multiple Inheritance in C++
    An Operational Semantics and Type Safety Proof for Multiple Inheritance in C++ Daniel Wasserrab Tobias Nipkow Gregor Snelting Frank Tip Universitat¨ Passau Technische Universitat¨ Universitat¨ Passau IBM T.J. Watson Research [email protected] Munchen¨ [email protected] Center passau.de [email protected] passau.de [email protected] Abstract pected type, or end with an exception. The semantics and proof are formalized and machine-checked using the Isabelle/HOL theorem We present an operational semantics and type safety proof for 1 multiple inheritance in C++. The semantics models the behaviour prover [15] and are available online . of method calls, field accesses, and two forms of casts in C++ class One of the main sources of complexity in C++ is a complex hierarchies exactly, and the type safety proof was formalized and form of multiple inheritance, in which a combination of shared machine-checked in Isabelle/HOL. Our semantics enables one, for (“virtual”) and repeated (“nonvirtual”) inheritance is permitted. Be- the first time, to understand the behaviour of operations on C++ cause of this complexity, the behaviour of operations on C++ class class hierarchies without referring to implementation-level artifacts hierarchies has traditionally been defined informally [29], and in such as virtual function tables. Moreover, it can—as the semantics terms of implementation-level constructs such as v-tables. We are is executable—act as a reference for compilers, and it can form only aware of a few formal treatments—and of no operational the basis for more advanced correctness proofs of, e.g., automated semantics—for C++-like languages with shared and repeated mul- program transformations.
    [Show full text]
  • Generic Programming
    Generic Programming July 21, 1998 A Dagstuhl Seminar on the topic of Generic Programming was held April 27– May 1, 1998, with forty seven participants from ten countries. During the meeting there were thirty seven lectures, a panel session, and several problem sessions. The outcomes of the meeting include • A collection of abstracts of the lectures, made publicly available via this booklet and a web site at http://www-ca.informatik.uni-tuebingen.de/dagstuhl/gpdag.html. • Plans for a proceedings volume of papers submitted after the seminar that present (possibly extended) discussions of the topics covered in the lectures, problem sessions, and the panel session. • A list of generic programming projects and open problems, which will be maintained publicly on the World Wide Web at http://www-ca.informatik.uni-tuebingen.de/people/musser/gp/pop/index.html http://www.cs.rpi.edu/˜musser/gp/pop/index.html. 1 Contents 1 Motivation 3 2 Standards Panel 4 3 Lectures 4 3.1 Foundations and Methodology Comparisons ........ 4 Fundamentals of Generic Programming.................. 4 Jim Dehnert and Alex Stepanov Automatic Program Specialization by Partial Evaluation........ 4 Robert Gl¨uck Evaluating Generic Programming in Practice............... 6 Mehdi Jazayeri Polytypic Programming........................... 6 Johan Jeuring Recasting Algorithms As Objects: AnAlternativetoIterators . 7 Murali Sitaraman Using Genericity to Improve OO Designs................. 8 Karsten Weihe Inheritance, Genericity, and Class Hierarchies.............. 8 Wolf Zimmermann 3.2 Programming Methodology ................... 9 Hierarchical Iterators and Algorithms................... 9 Matt Austern Generic Programming in C++: Matrix Case Study........... 9 Krzysztof Czarnecki Generative Programming: Beyond Generic Programming........ 10 Ulrich Eisenecker Generic Programming Using Adaptive and Aspect-Oriented Programming .
    [Show full text]