DOCSLIB.ORG

CLASS-XII COMPUTER SCIENCE FUNCTIONS and RECURSION NOTES MUTABLE and IMMUTABLE PROPERTIES of DATA OBJECT : in Python, Almost Ev

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CLASS-XII COMPUTER SCIENCE FUNCTIONS and RECURSION NOTES MUTABLE and IMMUTABLE PROPERTIES of DATA OBJECT : in Python, Almost Ev CLASS-XII COMPUTER SCIENCE FUNCTIONS AND RECURSION NOTES MUTABLE AND IMMUTABLE PROPERTIES OF DATA OBJECT : In Python, almost everything is an object. Numbers, strings, functions, classes, modules and even Python compiled code,all are objects. Python treats all variables as references to the object. This means all variables store the memory address of the actual object. This concept is much like “Pointer” in C and C++ programming language. This means the address of the actual object is stored in the Python named variable, not the value itself. Furthermore, immutable and mutable objects or variables are handled differently while working with function arguments. We will discuss them in below section. In the following diagram, variables a, b and name point to their memory locations where the actual value of the object is stored. Immutable Objects or Variables in Python In Python, immutable objects are those whose value cannot be changed in place after assignment or initialization. They allocate new memory whenever their value is changed. Examples of immutable data types or objects or variables in Python are numbers (integers, floats), strings and tuples. In above diagram, the value of variable b is changed from 11 to 8 after its assignment or initialization. b is an integer and it is an immutable variable. Hence, new memory is allocated for it and old is discarded. In other words, you can never overwrite the value of immutable objects. Every time you change the value of an immutable object, a new object is created in result. Old object is discarded and memory is cleaned up by garbage collector automatically for later use. So in first look, this seems inefficient but in practical it is not. This technique is also used in other very popular platforms like Java and .NET. Immutable Object or Variable Example with Explanation in Python x = 10 print("Value of x:", x) print("ID of x before modification 1 x = 10 2 print("Value of x:", x) 3 print("ID of x before modification:", id(x)) 4 5 # add 20 to the value of x 6 x += 20 7 8 print("Value of x:", x) 9 print("ID of x after modification:", id(x)) Result: Value of x: 10 ID of x before modification: 1528383264 Value of x: 20 ID of x after modification: 1528383584 Explanation: • As you can see memory address of x is changed after modification of value of x variable. This is clear that new memory location is allocated after modification of value of variable x Mutable Objects or Variables in Python In Python, list, dictionary and set are examples of mutable data types. Their values can be changed in place after their assignment or creation. When the value of a mutable variable is changed its memory is not reallocated. In the above diagram, individual string objects in the my_list are immutable but my_list itself is mutable. If we add, remove or modify individual string elements in my_list, the my_list variable points to same object. Mutable Object or Variable Example with Explanation in Python my_list = ["apple", "pear"] print("my_list:", my_list) print("ID of x before modification 1 my_list = ["apple", "pear"] 2 3 print("my_list:", my_list) 4 print("ID of x before modification:", id(my_list)) 5 6 # append "banana" to my_list 7 my_list.append("banana") 8 9 print("my_list:", my_list) 10 print("ID of x after modification:", id(my_list)) Result: my_list: ["apple", "pear"] ID of x before modification: 19925552 my_list: ["apple", "pear", "banana"] ID of x after modification: 19925552 Explanation: • As you can see, memory address of variable is not changed after modifying the object my_list • This has been discussed in detail with examples in this article below. Major Concepts of Function Argument Passing in Python Arguments are always passed to functions by reference in Python. The caller and the function code blocks share the same object or variable. When we change the value of a function argument inside the function code block scope, the value of that variable also changes inside the caller code block scope regardless of the name of the argument or variable. This concept behaves differently for both mutable and immutable arguments in Python. In Python, integer, float, string and tuple are immutable objects. list, dict and set fall in the mutable object category. This means the value of integer, float, string or tuple is not changed in the calling block if their value is changed inside the function or method block but the value of list, dict or set object is changed. Consider the mutable and immutable as states of the function arguments in Python. Let’s discuss it in detail with examples in the following section. Python Immutable Function Arguments Python immutable objects, such as numbers, tuple and strings, are also passed by reference like mutable objects, such as list, set and dict. Due to state of immutable (unchangeable) objects if an integer or string value is changed inside the function block then it much behaves like an object copying. A local new duplicate copy of the caller object inside the function block scope is created and manipulated. The caller object will remain unchanged. Therefore, caller block will not notice any changes made inside the function block scope to the immutable object. Let’s take a look at the following example. Python Immutable Function Argument – Example and Explanation def foo1(a): # function block a += 1 print('id of a:', id(a)) # id of y 1 def foo1(a): 2 # function block 3 a += 1 4 print('id of a:', id(a)) # id of y and a are same 5 return a 6 7 # main or caller block 8 x = 10 9 y = foo1(x) 10 11 # value of x is unchanged 12 print('x:', x) 13 14 # value of y is the return value of the function foo1 15 # after adding 1 to argument 'a' which is actual variable 'x' 16 print('y:', y) 17 18 print('id of x:', id(x)) # id of x 19 print('id of y:', id(y)) # id of y, different from x Result: id of a: 1456621360 x: 10 y: 11 id of x: 1456621344 id of y: 1456621360 Explanation: Parameter Passing "call by value" and "call by name" The most common evaluation strategy when passing arguments to a function has been call by value and call by reference: • Call by Value The most common strategy is the call-by-value evaluation, sometimes also called pass-by-value. This strategy is used in C and C++, for example. In call-by-value, the argument expression is evaluated, and the result of this evaluation is bound to the corresponding variable in the function. So, if the expression is a variable, a local copy of its value will be used, i.e. the variable in the caller's scope will be unchanged when the function returns. • Call by Reference In call-by-reference evaluation, which is also known as pass-by-reference, a function gets an implicit reference to the argument, rather than a copy of its value. As a consequence, the function can modify the argument, i.e. the value of the variable in the caller's scope can be changed. The advantage of call-by-reference consists in the advantage of greater time- and space- efficiency, because arguments do not need to be copied. On the other hand this harbors the disadvantage that variables can be "accidentally" changed in a function call. So special care has to be taken to "protect" the values, which shouldn't be changed. Many programming language support call-by-reference, like C or C++, but Perl uses it as default. If you pass immutable arguments like integers, strings or tuples to a function, the passing acts like call-by-value. The object reference is passed to the function parameters. They can't be changed within the function, because they can't be changed at all, i.e. they are immutable. It's different, if we pass mutable arguments. They are also passed by object reference, but they can be changed in place in the function. If we pass a list to a function, we have to consider two cases: Elements of a list can be changed in place, i.e. the list will be changed even in the caller's scope. If a new list is assigned to the name, the old list will not be affected, i.e. the list in the caller's scope will remain untouched. If you pass immutable arguments like integers, strings or tuples to a function, the passing acts like call-by-value. The object reference is First, let's have a look at the integer variables. The parameter inside of the function remains a reference to the arguments variable, as long as the parameter is not changed. As soon as a new value will be assigned to it, Python creates a separate local variable. The caller's variable will not be changed this way: def ref_demo(x): print "x=",x," id=",id(x) x=42 print "x=",x," id=",id(x) In the example above, we used the id() function, which takes an object as a parameter. id(obj) returns the "identity" of the object "obj". This identity, the return value of the function, is an integer which is unique and constant for this object during its lifetime. Two different objects with non-overlapping lifetimes may have the same id() value. If you call the function ref_demo() - like we do in the green block further down - we can check with the id() function what happens to x. We can see that in the main scope, x has the identity 41902552.
Load more

Recommended publications
  • Scala Tutorial
    Scala Tutorial SCALA TUTORIAL Simply Easy Learning by tutorialspoint.com tutorialspoint.com i ABOUT THE TUTORIAL Scala Tutorial Scala is a modern multi-paradigm programming language designed to express common programming patterns in a concise, elegant, and type-safe way. Scala has been created by Martin Odersky and he released the first version in 2003. Scala smoothly integrates features of object-oriented and functional languages. This tutorial gives a great understanding on Scala. Audience This tutorial has been prepared for the beginners to help them understand programming Language Scala in simple and easy steps. After completing this tutorial, you will find yourself at a moderate level of expertise in using Scala from where you can take yourself to next levels. Prerequisites Scala Programming is based on Java, so if you are aware of Java syntax, then it's pretty easy to learn Scala. Further if you do not have expertise in Java but you know any other programming language like C, C++ or Python, then it will also help in grasping Scala concepts very quickly. Copyright & Disclaimer Notice All the content and graphics on this tutorial are the property of tutorialspoint.com. Any content from tutorialspoint.com or this tutorial may not be redistributed or reproduced in any way, shape, or form without the written permission of tutorialspoint.com. Failure to do so is a violation of copyright laws. This tutorial may contain inaccuracies or errors and tutorialspoint provides no guarantee regarding the accuracy of the site or its contents including this tutorial. If you discover that the tutorialspoint.com site or this tutorial content contains some errors, please contact us at [email protected] TUTORIALS POINT Simply Easy Learning Table of Content Scala Tutorial ..........................................................................
    [Show full text]
  • 1 Aliasing and Immutability
    Vocabulary: Accessors & Mutators Computer Science and Engineering The Ohio State University Accessor: A method that reads, but never changes, the Aliasing and Immutability (abstract) state of an object Computer Science and Engineering College of Engineering The Ohio State University Concrete representation may change, so long as change is not visible to client eg Lazy initialization Examples: getter methods, toString Lecture 8 Formally: restores “this” Mutator method: A method that may change the (abstract) state of an object Examples: setter methods Formally: updates “this” Constructors not considered mutators A Fixed Epoch Interface A Broken Time Period Class Computer Science and Engineering The Ohio State University Computer Science and Engineering The Ohio State University // Interface cover story goes here public class Period implements FixedEpoch { // Mathematical modeling … private Date start; // constructor private Date end; // requires start date < end date // initializes start and end dates // operations have specifications based on the model public Period(Date start, Date end) { // exercises … this.start = start; this.e nd = e nd; public interface FixedEpoch { } public Date getStart(); public Date getEnd(); } public Date getStart() { return start; } public Date getEnd() { return end; } } Problem: Aliasing A Better Period Class Computer Science and Engineering The Ohio State University Computer Science and Engineering The Ohio State University Assignment in constructor creates an alias public class Period
    [Show full text]
  • Functional Programming Inside OOP?
    Functional Programming inside OOP? It’s possible with Python >>>whoami() Carlos Villavicencio ● Ecuadorian θ ● Currently: Python & TypeScript ● Community leader ● Martial arts: 剣道、居合道 ● Nature photography enthusiast po5i Cayambe Volcano, 2021. >>>why_functional_programming ● Easier and efficient ● Divide and conquer ● Ease debugging ● Makes code simpler and readable ● Also easier to test >>>history() ● Functions were first-class objects from design. ● Users wanted more functional solutions. ● 1994: map, filter, reduce and lambdas were included. ● In Python 2.2, lambdas have access to the outer scope. “Not having the choice streamlines the thought process.” - Guido van Rossum. The fate of reduce() in Python 3000 https://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html >>>has_django_fp() https://github.com/django/django/blob/46786b4193e04d398532bbfc3dcf63c03c1793cb/django/forms/formsets.py#L201-L213 https://github.com/django/django/blob/ca9872905559026af82000e46cde6f7dedc897b6/django/forms/formsets.py#L316-L328 Immutability An immutable object is an object whose state cannot be modified after it is created. Booleans, strings, and integers are immutable objects. List and dictionaries are mutable objects. Thread safety >>>immutability def update_list(value: list) -> None: def update_number(value: int) -> None: value += [10] value += 10 >>> foo = [1, 2, 3] >>> foo = 10 >>> id(foo) >>> update_number(foo) 4479599424 >>> foo >>> update_list(foo) 10 >>> foo 樂 [1, 2, 3, 10] >>> id(foo) 4479599424 >>>immutability def update_number(value: int) -> None: print(value, id(value)) value += 10 print(value, id(value)) >>> foo = 10 >>> update_number(foo) 10 4478220880 ڃ 4478221200 20 >>> foo 10 https://medium.com/@meghamohan/mutable-and-immutable-side-of-python-c2145cf72747 Decorators They are functions which modify the functionality of other functions. Higher order functions.
    [Show full text]
  • Gnu Smalltalk Library Reference Version 3.2.5 24 November 2017
    gnu Smalltalk Library Reference Version 3.2.5 24 November 2017 by Paolo Bonzini Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". 1 3 1 Base classes 1.1 Tree Classes documented in this manual are boldfaced. Autoload Object Behavior ClassDescription Class Metaclass BlockClosure Boolean False True CObject CAggregate CArray CPtr CString CCallable CCallbackDescriptor CFunctionDescriptor CCompound CStruct CUnion CScalar CChar CDouble CFloat CInt CLong CLongDouble CLongLong CShort CSmalltalk CUChar CByte CBoolean CUInt CULong CULongLong CUShort ContextPart 4 GNU Smalltalk Library Reference BlockContext MethodContext Continuation CType CPtrCType CArrayCType CScalarCType CStringCType Delay Directory DLD DumperProxy AlternativeObjectProxy NullProxy VersionableObjectProxy PluggableProxy SingletonProxy DynamicVariable Exception Error ArithmeticError ZeroDivide MessageNotUnderstood SystemExceptions.InvalidValue SystemExceptions.EmptyCollection SystemExceptions.InvalidArgument SystemExceptions.AlreadyDefined SystemExceptions.ArgumentOutOfRange SystemExceptions.IndexOutOfRange SystemExceptions.InvalidSize SystemExceptions.NotFound SystemExceptions.PackageNotAvailable SystemExceptions.InvalidProcessState SystemExceptions.InvalidState
    [Show full text]
  • Secure the Clones - Static Enforcement of Policies for Secure Object Copying Thomas Jensen, Florent Kirchner, David Pichardie
    Secure the Clones - Static Enforcement of Policies for Secure Object Copying Thomas Jensen, Florent Kirchner, David Pichardie To cite this version: Thomas Jensen, Florent Kirchner, David Pichardie. Secure the Clones - Static Enforcement of Policies for Secure Object Copying. ESOP 2011, 2011, Saarbrucken, Germany. hal-01110817 HAL Id: hal-01110817 https://hal.inria.fr/hal-01110817 Submitted on 28 Jan 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. Secure the Clones * Static Enforcement of Policies for Secure Object Copying Thomas Jensen, Florent Kirchner, and David Pichardie INRIA Rennes – Bretagne Atlantique, France [email protected] Abstract. Exchanging mutable data objects with untrusted code is a delicate matter because of the risk of creating a data space that is accessible by an attacker. Consequently, secure programming guidelines for Java stress the importance of using defensive copying before accepting or handing out references to an inter- nal mutable object. However, implementation of a copy method (like clone()) is entirely left to the programmer. It may not provide a sufficiently deep copy of an object and is subject to overriding by a malicious sub-class. Currently no language-based mechanism supports secure object cloning.
    [Show full text]
  • Enforcing Abstract Immutability
    Enforcing Abstract Immutability by Jonathan Eyolfson A thesis presented to the University of Waterloo in fulfillment of the thesis requirement for the degree of Doctor of Philosophy in Electrical and Computer Engineering Waterloo, Ontario, Canada, 2018 © Jonathan Eyolfson 2018 Examining Committee Membership The following served on the Examining Committee for this thesis. The decision of the Examining Committee is by majority vote. External Examiner Ana Milanova Associate Professor Rensselaer Polytechnic Institute Supervisor Patrick Lam Associate Professor University of Waterloo Internal Member Lin Tan Associate Professor University of Waterloo Internal Member Werner Dietl Assistant Professor University of Waterloo Internal-external Member Gregor Richards Assistant Professor University of Waterloo ii I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners. I understand that my thesis may be made electronically available to the public. iii Abstract Researchers have recently proposed a number of systems for expressing, verifying, and inferring immutability declarations. These systems are often rigid, and do not support “abstract immutability”. An abstractly immutable object is an object o which is immutable from the point of view of any external methods. The C++ programming language is not rigid—it allows developers to express intent by adding immutability declarations to methods. Abstract immutability allows for performance improvements such as caching, even in the presence of writes to object fields. This dissertation presents a system to enforce abstract immutability. First, we explore abstract immutability in real-world systems. We found that developers often incorrectly use abstract immutability, perhaps because no programming language helps developers correctly implement abstract immutability.
    [Show full text]
  • Exploring Language Support for Immutability
    Exploring Language Support for Immutability Michael Coblenz∗, Joshua Sunshine∗, Jonathan Aldrich∗, Brad Myers∗, Sam Webery, Forrest Shully May 8, 2016 CMU-ISR-16-106 This is an extended version of a paper that was published at ICSE [11]. Institute for Software Research School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 ∗School of Computer Science, Carnegie Mellon University, Pittsburgh, PA, USA ySoftware Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, USA This material is supported in part by NSA lablet contract #H98230-14-C-0140, by NSF grant CNS-1423054, and by Contract No. FA8721-05-C-0003 with CMU for the operation of the SEI, a federally funded research and development center sponsored by the US DoD. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect those of any of the sponsors. Keywords: Programming language design, Programming language usability, Immutability, Mutability, Program- mer productivity, Empirical studies of programmers Abstract Programming languages can restrict state change by preventing it entirely (immutability) or by restricting which clients may modify state (read-only restrictions). The benefits of immutability and read-only restrictions in software structures have been long-argued by practicing software engineers, researchers, and programming language designers. However, there are many proposals for language mechanisms for restricting state change, with a remarkable diversity of tech- niques and goals, and there is little empirical data regarding what practicing software engineers want in their tools and what would benefit them. We systematized the large collection of techniques used by programming languages to help programmers prevent undesired changes in state.
    [Show full text]
  • 1 Immutable Classes
    A Broken Time Period Class Computer Science and Engineering The Ohio State University public class Period { private Date start; Immutable Classes private Date end; Computer Science and Engineering College of Engineering The Ohio State University public Period(Date start, Date end) { assert (start.compareTo(end) > 0); //start < end this.start = start; this.end = end; Lecture 8 } public Date getStart() { return start; } public Date getEnd() { return end; } } Questions Problem: Aliasing Computer Science and Engineering The Ohio State University Computer Science and Engineering The Ohio State University What is an invariant in general? Assignment in constructor creates an alias Ans: Client and component both have references to the same Date object Class invariant can be undermined via alias What is an invariant for class Period? Date start = new Date(300); Ans: Date end = new Date (500); Period p = new Period (start, end); end.setTime(100); //modifies internals of p Why is this an invariant for this class? Solution: “defensive copying” Ans: Constructor creates a copy of the arguments Copy is used to initialize the private fields Metaphor: ownership A Better Period Class Good Practice: Copy First Computer Science and Engineering The Ohio State University Computer Science and Engineering The Ohio State University public class Period { private Date start; When making a defensive copy of private Date end; constructor arguments: public Period(Date start, Date end) { First copy the arguments assert (start.compareTo(end) >
    [Show full text]
  • Adding Crucial Features to a Typestate-Oriented Language
    João Daniel da Luz Mota Bachelor in Computer Science and Engineering Coping with the reality: adding crucial features to a typestate-oriented language Dissertation submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science and Engineering Adviser: António Maria Lobo César Alarcão Ravara, Associate Professor, NOVA School of Science and Technology Co-adviser: Marco Giunti, Researcher, NOVA School of Science and Technology Examination Committee Chair: Hervé Miguel Cordeiro Paulino, Associate Professor, NOVA School of Science and Technology Rapporteur: Ornela Dardha, Lecturer, School of Computing Science, University of Glasgow Members: António Maria Lobo César Alarcão Ravara Marco Giunti February, 2021 Coping with the reality: adding crucial features to a typestate-oriented lan- guage Copyright © João Daniel da Luz Mota, NOVA School of Science and Technology, NOVA University Lisbon. The NOVA School of Science and Technology and the NOVA University Lisbon have the right, perpetual and without geographical boundaries, to file and publish this dissertation through printed copies reproduced on paper or on digital form, or by any other means known or that may be invented, and to disseminate through scientific repositories and admit its copying and distribution for non-commercial, educational or research purposes, as long as credit is given to the author and editor. Acknowledgements Throughout the writing of this thesis I have received a great deal of support and assis- tance. I would first like to thank my adviser, Professor António Ravara, and co-adviser, Re- searcher Marco Giunti, for the guidance and direction provided. Your feedback was crucial and allowed me to organize my work and write this thesis.
    [Show full text]
  • Lazy Object Copy As a Platform for Population-Based Probabilistic Programming
    Lazy object copy as a platform for population-based probabilistic programming Lawrence M. Murray Uber AI Abstract This work considers dynamic memory management for population-based probabilistic programs, such as those using particle methods for inference. Such programs exhibit a pattern of allocating, copying, potentially mutating, and deallocating collections of similar objects through successive generations. These objects may assemble data structures such as stacks, queues, lists, ragged arrays, and trees, which may be of random, and possibly unbounded, size. For the simple case of N particles, T generations, D objects, and resampling at each generation, dense representation requires O(DNT ) memory, while sparse representation requires only O(DT + DN log DN) memory, based on existing theoretical results. This work describes an object copy-on-write platform to automate this saving for the programmer. The core idea is formalized using labeled directed multigraphs, where vertices represent objects, edges the pointers between them, and labels the necessary bookkeeping. A specific labeling scheme is proposed for high performance under the motivating pattern. The platform is implemented for the Birch probabilistic programming language, using smart pointers, hash tables, and reference-counting garbage collection. It is tested empirically on a number of realistic probabilistic programs, and shown to significantly reduce memory use and execution time in a manner consistent with theoretical expectations. This enables copy-on-write for the imperative programmer, lazy deep copies for the object-oriented programmer, and in-place write optimizations for the functional programmer. 1 Introduction Probabilistic programming aims at better accommodating the workflow of probabilistic modeling and inference in general-purpose programming languages.
    [Show full text]
  • Concurrent Copying Garbage Collection with Hardware Transactional Memory
    Concurrent Copying Garbage Collection with Hardware Transactional Memory Zixian Cai 蔡子弦 A thesis submitted in partial fulfilment of the degree of Bachelor of Philosophy (Honours) at The Australian National University November 2020 © Zixian Cai 2020 Typeset in TeX Gyre Pagella, URW Classico, and DejaVu Sans Mono by XƎTEX and XƎLATEX. Except where otherwise indicated, this thesis is my own original work. Zixian Cai 12 November 2020 To 2020, what does not kill you makes you stronger. Acknowledgments First and foremost, I thank my shifu1, Steve Blackburn. When I asked you how to learn to do research, you said that it often takes the form of an apprenticeship. Indeed, you taught me the craft of research by example, demonstrating how to be a good teacher, a good researcher, and a good community leader. Apart from the vast technical ex- pertise, you have also been a constant source of advice, support, and encouragement throughout my undergraduate career. I could not ask for a better mentor. I thank Mike Bond from The Ohio State University, who co-supervises me. Meet- ings with you and Steve are always enjoyable for me. I am sorry for the meetings that went over time, often around the dinner time for you, lowering your glucose level. You help me turn complicated ideas into implementation with your experiences in hard- ware transactional memory. I am thankful for your patient guidance and inspiration. Many people have helped me with this thesis. I thank Adrian Herrera, Kunal Sa- reen, and Brenda Wang for subjecting themselves to the draft of this document, and providing valuable feedback.
    [Show full text]
  • Obstacl: a Language with Objects, Subtyping, and Classes
    OBSTACL: A LANGUAGE WITH OBJECTS, SUBTYPING, AND CLASSES A DISSERTATION SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY By Amit Jayant Patel December 2001 c Copyright 2002 by Amit Jayant Patel All Rights Reserved ii I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. John Mitchell (Principal Adviser) I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. Kathleen Fisher I certify that I have read this dissertation and that in my opin- ion it is fully adequate, in scope and quality, as a dissertation for the degree of Doctor of Philosophy. David Dill Approved for the University Committee on Graduate Studies: iii Abstract Widely used object-oriented programming languages such as C++ and Java support soft- ware engineering practices but do not have a clean theoretical foundation. On the other hand, most research languages with well-developed foundations are not designed to support software engineering practices. This thesis bridges the gap by presenting OBSTACL, an object-oriented extension of ML with a sound theoretical basis and features that lend themselves to efficient implementation. OBSTACL supports modular programming techniques with objects, classes, structural subtyping, and a modular object construction system. OBSTACL's parameterized inheritance mechanism can be used to express both single inheritance and most common uses of multiple inheritance.
    [Show full text]