类型继承与关系理论：子类型、超类型与代换原则

需积分: 10 162 浏览量更新于2024-07-20 1 收藏 10.56MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

xiv Preface

oriented.” Note: I don’t mean to be offensive here; I mean, I don’t intend the foregoing

remarks to be taken as disparaging object languages as such. Rather, the reason I think it

might be desirable for you to be familiar with at least one language that’s not an object

language is the following. Suppose the only languages you know do in fact happen all to

be object languages. Then I’m afraid you might find you need to do some unlearning—

and as we all know, unlearning can often be quite difficult to do. For example, in object

languages, an object of, say, type NAME typically doesn’t contain a name as such; rather,

it contains a pointer, or “reference,” to such a name. By contrast, in the type theory

described in and embraced by the present book, the counterpart of such an object would

contain a name as such. (The reasons for this difference in approach are discussed in

detail in the body of the book, in Chapters 13 and 21 in particular.)

Here now by contrast are some things I won’t be assuming:

! I won’t assume you have a deep knowledge of the type system of whatever programming

language(s) you do happen to know, nor of type theory in general.

! I won’t you assume you know anything about SQL in particular (which is in fact basically

just another programming language, though it’s not usually described as such). Of

course, I don’t mean I’m going to be explaining a lot of SQL material that you might

already know; rather, I mean that—except for one rather long chapter, Chapter 22, which

in any case you can skip if you want—this book isn’t really about SQL, as such, at all.

Let me add a couple of further remarks regarding SQL, though. First, please note that

throughout the book all references to SQL should be understood as referring to the standard

version of that language exclusively, not to some proprietary dialect. The reference document is:

International Organization for Standardization (ISO): Database Language SQL, Document

ISO/IEC 9075:2008 (2011)

Second, please note that I follow the standard in assuming the pronunciation “ess cue ell,”

not “sequel” (though this latter pronunciation is common in the field), thereby saying things like

an SQL table, not a SQL table.

Structure of the Book

The book is arranged into five principal parts, as follows:

I. Preliminaries

Preface xv

II. Scalar Types, Single Inheritance

III. Scalar Types, Multiple Inheritance

IV. Tuple and Relation Inheritance

V. Other Approaches

There are also three appendixes and an index. Broadly speaking, the book is meant to be

read in sequence as written, except occasionally as noted here and there in the text itself; most of

the chapters do rely to some extent on material covered in earlier ones, so you shouldn’t jump

around too much. (However, let me draw your attention to the glossary in Appendix C; you

might find it convenient to refer to that glossary from time to time while reading other parts of

the book.)

Now, you might know that Darwen and I have written on this subject before, primarily in

our series of books on The Third Manifesto (see Chapter 1). However, what follows is much

more than just a cobbling together of material from those earlier writings. For one thing, it

contains much that’s entirely new. For another, it presents a more coherent, and I think much

better, perspective on the subject as a whole (I learned a lot myself in putting the book together).

Indeed, even when some portion of the text is based on earlier writings by ourselves, the material

in question has been totally rewritten and, I trust, improved.

All of that being said, I think I need to say too that the subject of inheritance does seem to

involve a certain amount of intrinsic complexity (a fact that accounts in part for the length of the

book, of course). Naturally I’ve done my best to explain the topics as straightforwardly as I can;

however, although the basic idea is simple enough, the devil is in the detail—and I do believe

you need to be exposed to that detail, even if you don’t absorb it all, in order to get a proper

sense of the scope of the subject.

Talking of complexity, I’m a little embarrassed at the number of footnotes in this book.

I’m only too well aware how annoying footnotes can be—indeed, they can seriously impede

readability—but in the present case I think they merely reflect what I referred to in the previous

paragraph as the intrinsic complexity of the subject matter. In fact, it occurred to me in writing

this preface that I might turn this plague of footnotes to some kind of advantage. To be specific,

noting that some chapters certainly seemed to involve rather more than their share, it occurred to

me that it might be helpful to the reader if I were to use “average number of footnote lines per

page” as a kind of rough and ready measure of relative complexity. To that end, I compiled the

following histogram, showing chapters and appendixes along the horizontal axis and “footnote

lines per page,” measured in units of one tenth, along the vertical axis. For example, the

histogram shows that Chapter 1 has an average of 2.5 footnote lines per page. Of course, I make

no great claims of either accuracy or precision in this connection, but I do think the histogram

gives some overall sense of which chapters might be a little harder, and which a little easier, to

come to grips with.

xvi Preface

630│ █

620│ █

610│ █

600│ █

590│ █

580│ █

570│ █

560│ █

550│ █

540│ █

530│ █

520│ █

510│ █

500│ █

490│ █

480│ █

470│ █

460│ █

450│ █

440│ █

430│ █

420│ █ █

410│ █ █

400│ █ █

390│ █ █

380│ █ █

370│ █ █

360│ █ █

350│ █ █

340│ █ █

330│ █ █

320│ █ █

310│ █ █ █

300│ █ █ █

290│ █ █ █

280│ █ █ █

270│ █ █ █ █

260│ █ █ █ █

250│ █ █ █ █ █ █

240│ █ █ █ █ █ █

230│ █ █ █ █ █ █ █

220│ █ █ █ █ █ █ █

210│ █ █ █ █ █ █ █ █ █ █

200│ █ █ █ █ █ █ █ █ █ █

190│ █ █ █ █ █ █ █ █ █ █ █ █

180│ █ █ █ █ █ █ █ █ █ █ █ █

170│ █ █ █ █ █ █ █ █ █ █ █ █ █

160│ █ █ █ █ █ █ █ █ █ █ █ █ █ █

150│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

140│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

130│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

120│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

110│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

100│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

90│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

80│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

70│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

60│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

50│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

40│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

30│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

20│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

10│ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █ █

└──────────────────────────────────────────────────────────────────────────

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 A B C

Some of the entries in this histogram deserve a little further explanation. First, the column

for Chapter 1 is surprisingly high. Actually I don’t think you should find that chapter very

difficult at all; it deals with history and other background material, and has more of a narrative

Preface xvii

feel to it than most of the other chapters. But it does contain several footnotes that give

references to other publications, and that fact might account for its comparatively high “relative

complexity” score. Similar remarks apply to Appendix B.

Second, the column for Chapter 4 is empty, and yet that chapter is probably the most

difficult in the book! But that’s because it consists essentially of just a formal statement of the

prescriptions of our model of inheritance, with almost nothing by way of further explanation, and

no footnotes either. The chapter is provided primarily for purposes of subsequent reference; it’s

certainly not meant to be read straight through.

Third, the columns for Chapters 21 and (especially) 22 are clearly the highest of all—a

state of affairs that doesn’t surprise me, because I spent more time on those two chapters than I

did on the entire rest of the book put together. And the reason I did so was because, in my

opinion, the technical material I was trying to describe in those chapters is rather confusing, and

(I’m tempted to say) rather confused as well. Perhaps a kinder way to put it is that the material

in question does seem to be ad hoc to a degree, instead of being founded, as we claim our own

inheritance model is, on a clear and well thought out set of underlying principles. Be that as it

may, I certainly do think those two chapters are quite difficult. Now, I’m sorry that such is the

case, and I apologize for it—but I don’t think the fault is entirely mine.

Acknowledgments

As I’ve said, I do believe our model of type inheritance has something truly useful to offer—all

the more so, perhaps, because it’s so different from other approaches to the subject that have

been described in the literature. For that reason, I’d been thinking for some time about a book

like this one, one that I hoped could provide a coherent and reasonably complete description of

what it was that we were proposing. (After all, those earlier writings by Darwen and myself

didn’t really do our proposals justice, and in any case those writings were neither complete nor

entirely self-contained. At least, so it seemed to me.) But pressure of other work prevented me

from getting down to the task until comparatively recently. What finally spurred me into action

was a series of relevant technical questions—sometimes quite tricky ones!—from various

interested parties, which made me realize that the best way of dealing with such questions was to

get on and write the book, once and for all.

So I’m grateful in the first place to everyone who asked such questions, including attendees

at live classes, readers of earlier books of mine, and members of the Third Manifesto community

in general. Talking of classes, incidentally, I’d like to say that almost all of the ideas discussed

in this book—in all of my books, as a matter of fact—have been taught and discussed in live

classes before being brought to their current documented form. In my opinion this is a very good

In my defense here, I’m tempted to invoke what elsewhere I’ve called The Principle of Incoherence. To quote from my book

The New Relational Database Dictionary (O’Reilly, 2016), The Principle of Incoherence (referred to by some, a little unkindly,

as The Incoherent Principle) is “[a] principle, sometimes invoked in defense of an attempt (successful or otherwise) at criticizing

some technical proposal or position, to the effect that it’s hard to criticize something coherently if what’s being criticized is itself

not very coherent in the first place—a state of affairs that goes some way toward explaining why such criticisms can often be

longer than what’s being criticized.”

xviii Preface

way to try out ideas to see if they make sense: to make sure that they hang together, as it were,

and in particular that they’re teachable. I do believe teachability is a good test of the quality of a

language. One of the reasons the SQL standard is in the sorry state it’s in, I’m convinced, is

because the SQL definers seem not to have tried the experiment of teaching what they’re

defining in a live class. If they had, they would surely have realized what’s wrong with it and

made appropriate changes to the language. But now I’m getting on a hobby horse ... Let me get

back to the acknowledgments.

Second, then, I’m grateful to my technical reviewers Hugh Darwen, Erwin Smout, and

Dave Voorhis. Between them, they provided me with the most meticulous reviews a technical

writer could possibly wish for. (Mind you, I can’t claim to have adopted all of their

suggestions!—so, while those suggestions certainly resulted in a vastly improved book, I bear

full responsibility for the final text.) Be that as it may, I’m particularly pleased to be able to tell

you that Erwin and Dave are responsible for SIRA-PRISE (

SIRA_PRISE@edpnet.be

) and Rel

(

http://dbappbuilder.sourceforge.net/Rel.html

), respectively; each of these projects consists of a

comprehensive implementation of Third Manifesto ideas, including in both cases partial support

for the inheritance model described in this book. As for Hugh, not only did he very kindly

contribute an interesting historical foreword, but his detailed comments on the manuscript,

together with much subsequent technical correspondence, led to a number of revisions to the

inheritance model itself; thus, that model should most definitely be understood as a joint

production by the two of us.

Third, I’d like to thank my wife Lindy, as always, for her support throughout this and all of

my other database projects over the years.

Finally, I’m grateful to everyone at O’Reilly for their encouragement, contributions, and

support throughout the production of this book.

C. J. Date

Healdsburg, California

2016

剩余571页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

类型继承与关系理论：子类型、超类型与代换原则

Python库 | eea.faceted.inheritance-4.5.zip

What type of inheritance has the following syntax? Syntax class A { // body of the class A. } class B : access-specifier A { // body of class B. } class C : access-specifier A { // body of class C. } a. Multilevel Inheritance b. Multiple Inheritance c. Hierarchical Inheritance d. Hybrid Inheritance

the difference between to inheritance compostion

please introduce a number of OOP features (e.g. encapsulation) and principles (e.g. single responsibility principle).

In OOP, are Polymorphism and Inheritance the same?

java Inheritance

java课程设计单词簿

android 写入inheritance_hierachy.json怎么操作

java 中常用英语_java中常用英语

java inheritance

学Java要掌握的英语单词

java.lang.String cannot be cast to java.lang.Integer

How to implement interface inheritance when. net7 is not in the domain service

基于JavaWeb开发的图书管理系统 (源码+数据库).zip-大作业&课程设计

武汉工程大学邮电与信息工程学院在广东2021-2024各专业最低录取分数及位次表.pdf

最新资源