DOCSLIB.ORG

Subtyping Is Not a Good \Match" for Object-Oriented Languages ?

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Subtyping Is Not a Good \Match Subtyping is not a go o d \Match" for ? ob ject-oriented languages 1 1 ?? 2 Kim B. Bruce ,LeafPetersen , and Adrian Fiech 1 Williams College, Williamstown, MA, USA 2 Memorial University of Newfoundland, St. John's, Newfoundland, Canada Abstract. Wepresent the design and rationale of a new statically-typ ed ob ject-oriented language, LO O M. LOOM retains most of the features of the earlier language PolyTOIL. However the subtyping relation is dropp ed from LOOM in favor of the matching relation. \Hash typ es", which are de ned in terms of matching, are intro duced to provide some of the b ene ts of subtyping. These typ es can b e used to provide supp ort for heterogeneous data stuctures in LOOM. LO O M is considerably sim- pler than PolyTOIL,yet is just as expressive. The typ e system for the language is decidable and provably typ e safe. The addition of mo dules to the language provides b etter control over information hiding and allows the provision of access like that of C++'s friends. 1 Intro duction Most statically-typ ed ob ject-oriented programming languages, including C++ + [ES90], Java [AG96], Ob ject Pascal [Tes85], and Mo dula 3 [CDG 88], su er from very rigid typ e systems whichcanblock the easy expression of program- mers' ideas, particularly in the de nition of sub classes. Other statically-typ ed ob ject-oriented languages, such as Ei el [Mey92] and Beta [MMMP90], are more exible, but require run-time or link-time checks in order to eliminate holes in the typ e system. One imp ortantgoalof our previous work in designing static typ e systems for ob ject-oriented languages has b een to design exible, yet safe, static typ e systems (see for example [Bru93, Bru94, BSvG95]). In this pap er we prop ose a fairly radical departure from previous statically-typ ed ob ject-oriented languages by dropping subtyping in favor of a relation called matching and a new typ e constructor related to matching. It has b ecome clear in the last several years that the concepts of inheritance and subtyping in ob ject-oriented languages are not at all the same. (See [Sny86] for early hints, and [CHC90, AvdL90, LP91] for more de nitive treatments of the topic.) In earlier pap ers [Bru93,Bru94, BSvG95], weintro duced the notion of matching, a relation b etween ob ject typ es which is more general than subtyping. ? Bruce and Petersen's researchwas partially supp orted by NSF grant CCR-9424123. Fiech's researchwas partially supp orted by NSERCgrant OGP0170497. ?? Current address: Scho ol of Computer Science, Carnegie-Mellon University, Pitts- burgh, PA, USA A history of matching can b e found in [BSvG95]. See also [AC95] for a discussion of explanations of matching in terms of F-b ounded and higher-order subtyping. An imp ortant feature of matching is that if two classes are sub classes, then the corresp onding ob ject typ es are in the matching relation. However, these typ es are not generally in the subtyp e relation if the language includes a typ e expression, MyType, standing for the typ e of self. Since MyType is extremely valuable, we end up with a mismatchbetween subtyping and inheritance. The language PolyTOIL [BSvG95] supp orts b oth subtyping and matching. It also supp orts b ounded p olymorphism where the b ounds on typ e parameters are given in terms of the matching relation. Unfortunately, the relations of matching and subtyping are similar enough that it might b e dicult for a programmer to keep their di erences straight. As a result we b egan considering the p ossibility of simplifying the language by dropping one or the other. It was clear that matching was absolutely necessary in PolyTOIL in order to express the typ e-checking rules for sub classes, as well as to provide constraints for p olymorphic op erations and data structures. Subtyping was to o restrictive to serve either of these purp oses. Moreover, as welooked at the sample programs we had written in PolyTOIL, we noticed that we rarely used subtyping. In the presence of MyType and match-b ounded p olymorphism, we almost never needed to explicitly change the typ es of metho ds in sub classes. With this in mind, we decided to be bold and investigate the results of eliminating subtyping in favor of matching. While this caused no problems with the inheritance mechanism, we did discover a few situations where we found it dicult to do without subtyping. To deal with this we intro duced a new typ e constructor, #T ,which represents elements whose typ es matchthetyp e T. With this addition, we found that we had a language whichwas essentially as expressiveas PolyTOIL ,yet signi cantly less complex. In the next section we review brie y the main features of PolyTOIL . In section 3 we intro duce the language LOOM. We pay sp ecial attention to the intro duction of a new typ e constructor which can b e applied to ob ject typ es to form typ es whichhave prop erties similar to subtyp es (but are less restrictive). In the following section weprovide a brief overview of the technical results used to justify the use of the language: typ e-checking is decidable and the language is provably typ e-safe. Weprovide a brief overview of LO O M 's mo dule system in section 5. Finally in section 6 we summarize and evaluate the features of the language. 2 Intro duction to PolyTOIL and Matching In [BSvG95]weintro duced PolyTOIL , a statically-typ ed ob ject-oriented pro- gramming language which provides all of the usual constructs of class-based ob ject-oriented languages. In particular, it supp orts ob jects which consist of instance variables and metho ds, and in which computation is based on message- sending. Reuse is supp orted via inheritance, subtyping, and a form of b ounded p olymorphism. We refer the reader to [BSvG95] for the details of the language. Weprovide only a brief summary here. Relatively innovative features of the language include: { The use of MyType in classes to refer to the typ e of self, the receiver of the message. { The treatment of classes as rst-class values of the language. They have typ es and can b e b oth parameters to functions and returned as the results of functions. { The separation of the inheritance and subtyping hierarchies, in order to avoid problems which can arise with so-called binary metho ds. { The intro duction of a new ordering called \matching", written <# , which corresp onds closely to typ e changes allowed in de ning sub classes. Subtyp- ing, written <: , is also supp orted. { Supp ort for a form of b ounded p olymorphism, called match-bounded poly- morphism in which the b ound is expressed in terms of the new matching ordering. Within the scop e of each ob ject (or class), PolyTOIL de nes a typ e identi er MyType that represents the typ e of the ob ject itself. This typ e is \anchored" to the typ e of the ob ject in which it app ears, so that an app earance of MyType in the typ e of a metho d inherited from another class represents the typ e of an instance of the current class, rather than the parent class in which the metho d was de ned. Matching is a relation b etween typ es whichisvery similar to subtyping, but is designed to corresp ond b etter to the inheritance hierarchy of classes and ob jects. An ob ject typ e matches an ob ject typ e in PolyTOIL , if for every metho d m : included in ob ject typ e there is a corresp onding metho d m : included i i i i in ob ject typ e suchthat <: (where o ccurrences of the keyword MyType i i in the metho d typ es are treated as uninterpreted free variables). The de nition of subtyping for ob ject typ es is similar to that for match- 3 ing, but also requires that MyType only o ccur p ositively in metho d typ es (see [BSvG95] for de nitions and details). In particular, an ob ject typ e with a metho d with parameter of typ e MyType cannot haveany non-trivial subtyp es. As a re- sult, if a class has a metho d with a parameter of typ e MyType, then sub classes will not giverisetosubtyp es. While <: implies that any elementoftyp e can b e treated as b eing of typ e , the imp ort of matching is weaker. If <# then any message senttoan ob ject of the typ e could also b e sent to an ob ject of typ e . MyType and matching are crucial to the expressiveness of PolyTOIL . My- Type is often used in expressing the typ es of metho ds whose typ es will need to change in sub classes. It app ears frequently in asso ciation with copy or clone 3 Roughly, an o ccurrence of an identi er is p ositive (or covariant) if it is on the left side of an even numb er of function typ es, and is negative (or contravariant) if it is on the left of an o dd numb er of function typ es. In particular, if the return typ e of a function is MyType, then that o ccurrence of MyType is p ositive. On the other hand, if a parameter typ e of a function is MyType, then that o ccurrence is negative.
Load more

Recommended publications
  • An Extended Theory of Primitive Objects: First Order System Luigi Liquori
    An extended Theory of Primitive Objects: First order system Luigi Liquori To cite this version: Luigi Liquori. An extended Theory of Primitive Objects: First order system. ECOOP, Jun 1997, Jyvaskyla, Finland. pp.146-169, 10.1007/BFb0053378. hal-01154568 HAL Id: hal-01154568 https://hal.inria.fr/hal-01154568 Submitted on 22 May 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. An Extended Theory of Primitive Objects: First Order System Luigi Liquori ? Dip. Informatica, Universit`adi Torino, C.so Svizzera 185, I-10149 Torino, Italy e-mail: [email protected] Abstract. We investigate a first-order extension of the Theory of Prim- itive Objects of [5] that supports method extension in presence of object subsumption. Extension is the ability of modifying the behavior of an ob- ject by adding new methods (and inheriting the existing ones). Object subsumption allows to use objects with a bigger interface in a context expecting another object with a smaller interface. This extended calcu- lus has a sound type system which allows static detection of run-time errors such as message-not-understood, \width" subtyping and a typed equational theory on objects.
    [Show full text]
  • On Model Subtyping Cl´Ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´Ez´Equel
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by HAL-Rennes 1 On Model Subtyping Cl´ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´ez´equel To cite this version: Cl´ement Guy, Benoit Combemale, Steven Derrien, James Steel, Jean-Marc J´ez´equel.On Model Subtyping. ECMFA - 8th European Conference on Modelling Foundations and Applications, Jul 2012, Kgs. Lyngby, Denmark. 2012. <hal-00695034> HAL Id: hal-00695034 https://hal.inria.fr/hal-00695034 Submitted on 7 May 2012 HAL is a multi-disciplinary open access L'archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destin´eeau d´ep^otet `ala diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publi´esou non, lished or not. The documents may come from ´emanant des ´etablissements d'enseignement et de teaching and research institutions in France or recherche fran¸caisou ´etrangers,des laboratoires abroad, or from public or private research centers. publics ou priv´es. On Model Subtyping Clément Guy1, Benoit Combemale1, Steven Derrien1, Jim R. H. Steel2, and Jean-Marc Jézéquel1 1 University of Rennes1, IRISA/INRIA, France 2 University of Queensland, Australia Abstract. Various approaches have recently been proposed to ease the manipu- lation of models for specific purposes (e.g., automatic model adaptation or reuse of model transformations). Such approaches raise the need for a unified theory that would ease their combination, but would also outline the scope of what can be expected in terms of engineering to put model manipulation into action.
    [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]
  • 13 Templates-Generics.Pdf
    CS 242 2012 Generic programming in OO Languages Reading Text: Sections 9.4.1 and 9.4.3 J Koskinen, Metaprogramming in C++, Sections 2 – 5 Gilad Bracha, Generics in the Java Programming Language Questions • If subtyping and inheritance are so great, why do we need type parameterization in object- oriented languages? • The great polymorphism debate – Subtype polymorphism • Apply f(Object x) to any y : C <: Object – Parametric polymorphism • Apply generic <T> f(T x) to any y : C Do these serve similar or different purposes? Outline • C++ Templates – Polymorphism vs Overloading – C++ Template specialization – Example: Standard Template Library (STL) – C++ Template metaprogramming • Java Generics – Subtyping versus generics – Static type checking for generics – Implementation of Java generics Polymorphism vs Overloading • Parametric polymorphism – Single algorithm may be given many types – Type variable may be replaced by any type – f :: tt => f :: IntInt, f :: BoolBool, ... • Overloading – A single symbol may refer to more than one algorithm – Each algorithm may have different type – Choice of algorithm determined by type context – Types of symbol may be arbitrarily different – + has types int*intint, real*realreal, ... Polymorphism: Haskell vs C++ • Haskell polymorphic function – Declarations (generally) require no type information – Type inference uses type variables – Type inference substitutes for variables as needed to instantiate polymorphic code • C++ function template – Programmer declares argument, result types of fctns – Programmers
    [Show full text]
  • On the Interaction of Object-Oriented Design Patterns and Programming
    On the Interaction of Object-Oriented Design Patterns and Programming Languages Gerald Baumgartner∗ Konstantin L¨aufer∗∗ Vincent F. Russo∗∗∗ ∗ Department of Computer and Information Science The Ohio State University 395 Dreese Lab., 2015 Neil Ave. Columbus, OH 43210–1277, USA [email protected] ∗∗ Department of Mathematical and Computer Sciences Loyola University Chicago 6525 N. Sheridan Rd. Chicago, IL 60626, USA [email protected] ∗∗∗ Lycos, Inc. 400–2 Totten Pond Rd. Waltham, MA 02154, USA [email protected] February 29, 1996 Abstract Design patterns are distilled from many real systems to catalog common programming practice. However, some object-oriented design patterns are distorted or overly complicated because of the lack of supporting programming language constructs or mechanisms. For this paper, we have analyzed several published design patterns looking for idiomatic ways of working around constraints of the implemen- tation language. From this analysis, we lay a groundwork of general-purpose language constructs and mechanisms that, if provided by a statically typed, object-oriented language, would better support the arXiv:1905.13674v1 [cs.PL] 31 May 2019 implementation of design patterns and, transitively, benefit the construction of many real systems. In particular, our catalog of language constructs includes subtyping separate from inheritance, lexically scoped closure objects independent of classes, and multimethod dispatch. The proposed constructs and mechanisms are not radically new, but rather are adopted from a variety of languages and programming language research and combined in a new, orthogonal manner. We argue that by describing design pat- terns in terms of the proposed constructs and mechanisms, pattern descriptions become simpler and, therefore, accessible to a larger number of language communities.
    [Show full text]
  • A Core Calculus of Metaclasses
    A Core Calculus of Metaclasses Sam Tobin-Hochstadt Eric Allen Northeastern University Sun Microsystems Laboratories [email protected] [email protected] Abstract see the problem, consider a system with a class Eagle and Metaclasses provide a useful mechanism for abstraction in an instance Harry. The static type system can ensure that object-oriented languages. But most languages that support any messages that Harry responds to are also understood by metaclasses impose severe restrictions on their use. Typi- any other instance of Eagle. cally, a metaclass is allowed to have only a single instance However, even in a language where classes can have static and all metaclasses are required to share a common super- methods, the desired relationships cannot be expressed. For class [6]. In addition, few languages that support metaclasses example, in such a language, we can write the expression include a static type system, and none include a type system Eagle.isEndangered() provided that Eagle has the ap- with nominal subtyping (i.e., subtyping as defined in lan- propriate static method. Such a method is appropriate for guages such as the JavaTM Programming Language or C#). any class that is a species. However, if Salmon is another To elucidate the structure of metaclasses and their rela- class in our system, our type system provides us no way of tionship with static types, we present a core calculus for a requiring that it also have an isEndangered method. This nominally typed object-oriented language with metaclasses is because we cannot classify both Salmon and Eagle, when and prove type soundness over this core.
    [Show full text]
  • Polymorphic Subtyping in O'haskell
    Science of Computer Programming 43 (2002) 93–127 www.elsevier.com/locate/scico Polymorphic subtyping in O’Haskell Johan Nordlander Department of Computer Science and Engineering, Oregon Graduate Institute of Science and Technology, 20000 NW Walker Road, Beaverton, OR 97006, USA Abstract O’Haskell is a programming language derived from Haskell by the addition of concurrent reactive objects and subtyping. Because Haskell already encompasses an advanced type system with polymorphism and overloading, the type system of O’Haskell is much richer than what is the norm in almost any widespread object-oriented or functional language. Yet, there is strong evidence that O’Haskell is not a complex language to use, and that both Java and Haskell pro- grammers can easily ÿnd their way with its polymorphic subtyping system. This paper describes the type system of O’Haskell both formally and from a programmer’s point of view; the latter task is accomplished with the aid of an illustrative, real-world programming example: a strongly typed interface to the graphical toolkit Tk. c 2002 Elsevier Science B.V. All rights reserved. Keywords: Type inference; Subtyping; Polymorphism; Haskell; Graphical toolkit 1. Introduction The programming language O’Haskell is the result of a ÿnely tuned combination of ideas and concepts from functional, object-oriented, and concurrent programming, that has its origin in the purely functional language Haskell [36]. The name O’Haskell is a tribute to this parentage, where the O should be read as an indication of Objects,as well as a reactive breach with the tradition that views Input as an active operation on par with Output.
    [Show full text]
  • CS 6110 S18 Lecture 23 Subtyping 1 Introduction 2 Basic Subtyping Rules
    CS 6110 S18 Lecture 23 Subtyping 1 Introduction In this lecture, we attempt to extend the typed λ-calculus to support objects. In particular, we explore the concept of subtyping in detail, which is one of the key features of object-oriented (OO) languages. Subtyping was first introduced in Simula, the first object-oriented programming language. Its inventors Ole-Johan Dahl and Kristen Nygaard later went on to win the Turing award for their contribution to the field of object-oriented programming. Simula introduced a number of innovative features that have become the mainstay of modern OO languages including objects, subtyping and inheritance. The concept of subtyping is closely tied to inheritance and polymorphism and offers a formal way of studying them. It is best illustrated by means of an example. This is an example of a hierarchy that describes a Person Student Staff Grad Undergrad TA RA Figure 1: A Subtype Hierarchy subtype relationship between different types. In this case, the types Student and Staff are both subtypes of Person. Alternatively, one can say that Person is a supertype of Student and Staff. Similarly, TA is a subtype of the Student and Person types, and so on. The subtype relationship is normally a preorder (reflexive and transitive) on types. A subtype relationship can also be viewed in terms of subsets. If σ is a subtype of τ, then all elements of type σ are automatically elements of type τ. The ≤ symbol is typically used to denote the subtype relationship. Thus, Staff ≤ Person, RA ≤ Student, etc. Sometimes the symbol <: is used, but we will stick with ≤.
    [Show full text]
  • Structural Model Subtyping with OCL Constraints
    Structural Model Subtyping with OCL Constraints Artur Boronat Department of Informatics University of Leicester United Kingdom [email protected] Abstract 1 Introduction In model-driven engineering (MDE), models abstract the rel- Our aim in this work is to revisit the research question of evant features of software artefacts and model management whether type subsumption − i.e. the relation capturing that operations, including model transformations, act on them any inhabitant of a given subtype is also an inhabitant of a automating large tasks of the development process. Flexible given supertype − is a valid mechanism for facilitating reuse reuse of such operations is an important factor to improve of model management operations in MDE in order to analyse productivity when developing and maintaining MDE solu- its advantages and limitations. We approach this topic by tions. In this work, we revisit the traditional notion of object exposing a general problem involving reuse, which we then subtyping based on subsumption, discarded by other ap- solve by using structural model subtyping. proaches to model subtyping. We refine a type system for In a typed setting, model management operations are ap- object-oriented programming, with multiple inheritance, to plied to models that conform to metamodels, which define support model types in order to analyse its advantages and the abstract syntax of a modeling language. Additional well- limitations with respect to reuse in MDE. Specifically, we ex- formedness constraints can be added to the language, usually tend type expressions with referential constraints and with by encoding them in an OCL dialect. The notion of a pair OCL constraints.
    [Show full text]
  • CSCE 314 Programming Languages Java Generics II
    CSCE 314 Programming Languages ! Java Generics II Dr. Hyunyoung Lee ! ! ! !1 Lee CSCE 314 TAMU Type System and Variance Within the type system of a programming language, variance refers to how subtyping between complex types (e.g., list of Cats versus list of Animals, and function returning Cat versus function returning Animal) relates to subtyping between their components (e.g., Cats and Animals). !2 Lee CSCE 314 TAMU Covariance and Contravariance Within the type system of a programming language, a typing rule or a type constructor is: covariant if it preserves the ordering ≤ of types, which orders types from more specific to more generic contravariant if it reverses this ordering invariant if neither of these applies. !3 Lee CSCE 314 TAMU Co/Contravariance Idea Read-only data types can be covariant; Write-only data types can be contravariant; Mutable data types which support read and write operations should be invariant. ! Even though Java arrays are a mutable data type, Java treats array types covariantly, by marking each array object with a type when it is created. !4 Lee CSCE 314 TAMU Covariant Method Return Type Return types of methods in Java can be covariant: class Animal { . public Animal clone() { return new Animal(); } } class Panda extends Animal { . public Panda clone() { return new Panda(); } } This is safe - whenever we call Animal’s clone(), we get at least an Animal, but possibly something more (a subtype of Animal) Animal p = new Panda(); . Animal a = p.clone(); // returns a Panda, OK !5 Lee CSCE 314 TAMU Covariant Method Argument Type (Bad Idea) Would this be a good idea? class Animal { .
    [Show full text]
  • An Introduction to Subtyping
    An Introduction to Subtyping Type systems are to me the most interesting aspect of modern programming languages. Subtyping is an important notion that is helpful for describing and reasoning about type systems. This document describes much of what you need to know about subtyping. I’ve taken some of the definitions, notation, and presentation ideas in this document from Kim Bruce's text "Fundamental Concepts of Object-Oriented Languages" which is a great book and the one that I use in my graduate programming languages course. I’ve also borrowed ideas from Cardelli and Wegner. 1.1. What is Subtyping When is an assignment, x = y legal? There are at least two possible answers: 1. When x and y are of equal types 2. When y’s type can be “converted” to x’s type The discussion of name and structural equality (which we went into earlier in this course) takes care of the first aspect. What about the second aspect? When can a type be safely converted to another type? Remember that a type is just a set of values. For example, an INTEGER type is the set of values from minint to maxint, inclusive. Once we consider types as set of values, we realize immediately one set may be a subset of another set. [0 TO 10] is a subset of [0 TO 100] [0 TO 100] is a subset of INTEGER [0 TO 10] has a non-empty intersection with [5 TO 20] but is not a subset of [5 TO 20] When the set of values in one type, T, is a subset of the set of values in another type, U, we say that T is a subtype of U.
    [Show full text]
  • Lecture 5: File I/O, Advanced Unix, Enum/Struct/Union, Subtyping
    CIS 507: _ _ _ _ ______ _ _____ / / / /___ (_) __ ____ _____ ____/ / / ____/ _/_/ ____/__ __ / / / / __ \/ / |/_/ / __ `/ __ \/ __ / / / _/_// / __/ /___/ /_ / /_/ / / / / /> < / /_/ / / / / /_/ / / /____/_/ / /__/_ __/_ __/ \____/_/ /_/_/_/|_| \__,_/_/ /_/\__,_/ \____/_/ \____//_/ /_/ ! Lecture 5: File I/O, Advanced Unix, Enum/Struct/Union, Subtyping Oct. 23rd, 2018 Hank Childs, University of Oregon Project 3 • Time to get going on Project 3 • It is about 1000 lines of code File I/O File I/O: streams and file descriptors • Two ways to access files: – File descriptors: • Lower level interface to files and devices – Provides controls to specific devices • Type: small integers (typically 20 total) – Streams: • HigHer level interface to files and devices – Provides uniform interface; easy to deal with, but less powerful • Type: FILE * Streams are more portable, and more accessible to beginning programmers. (I teacH streams Here.) File I/O • Process for reading or wriNng – Open a file • Tells Unix you intend to do file I/O • FuncNon returns a “FILE * – Used to idenNfy the file from this point forward • CHecks to see if permissions are valid – Read from the file / write to the file – Close the file Opening a file • FILE *handle = fopen(filename, mode); Example: FILE *h = fopen(“/tmp/330”, “wb”); Close wHen you are done with “fclose” Note: #include <stdio.H> Reading / WriNng Example File PosiNon Indicator • File posiNon indicator: the current locaon in the file • If I read one byte, the one byte you get is wHere the file posiNon indicator is poinNng.
    [Show full text]