Path: news.cambrium.nl!textnews.cambrium.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.78.MISMATCH!feeder.news-service.com!postnews.google.com!m3g2000pri.googlegroups.com!not-for-mail From: Nilone Newsgroups: comp.databases.theory Subject: Re: Entity and Identity Date: Mon, 27 Jul 2009 07:25:21 -0700 (PDT) Organization: http://groups.google.com Lines: 72 Message-ID: <40785248-198c-4ff4-aa19-e77b841cfb13@m3g2000pri.googlegroups.com> References: <4a6a3350$0$18265$703f8584@news.kpn.nl> <337afd4f-e651-4060-a84b-58c0e904f3f5@h11g2000yqb.googlegroups.com> <1c5b2e68-a5c0-416c-840b-0bd8a6949f6d@q40g2000prh.googlegroups.com> <06c69bbc-cada-4efb-bed3-be2d9793a5cc@l2g2000vba.googlegroups.com> <4a6dae1d$0$23749$9a566e8b@news.aliant.net> <4a6db3b7$0$23759$9a566e8b@news.aliant.net> NNTP-Posting-Host: 196.210.223.239 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1248704725 21302 127.0.0.1 (27 Jul 2009 14:25:25 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 27 Jul 2009 14:25:25 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: m3g2000pri.googlegroups.com; posting-host=196.210.223.239; posting-account=jTAZ8QoAAABcV-JPHVPbQ2F6pRtag3Iu User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.2) Gecko/2008091620 Firefox/3.0.2 (.NET CLR 3.5.30729),gzip(gfe),gzip(gfe) Xref: news.cambrium.nl On Jul 27, 4:03=A0pm, Bob Badour wrote: > Nilone wrote: > > On Jul 27, 3:39 pm, Bob Badour wrote: > > >>Nilone wrote: > > >>>On Jul 27, 12:01 pm, David BL wrote: > > >>>>On Jul 27, 4:02 pm, Nilone wrote: > > >>><...snip...> > > >>>>>I'm concerned about your statement about LSP and subtyping state > >>>>>machines. =A0I just don't see how (or why) you would subtype a state > >>>>>machine. =A0I'll allow subtyping an interface and implementing a new > >>>>>state machine for it. > > >>>>That's actually what I meant. =A0A "type" of state machine is what yo= u > >>>>are calling an "interface". =A0 E.g. a SeekableInputStream is a subty= pe > >>>>of a InputStream. =A0It follows that a reference (to a state machine)= of > >>>>type SeekableInputStream can be upcast to a reference of type > >>>>InputStream. > > >>>>I think of types as completely divorced from implementation (for both > >>>>data types and state machine types). > > >>>>>LSP requires any property provable about objects of the base type to > >>>>>be provable of objects of the derived type. =A0Subtyping a state mac= hine > >>>>>would have little value, since you wouldn't be able to change any > >>>>>behaviour - "any property provable about the base type" would includ= e > >>>>>its exact behaviour. > > >>>>I agree that subclassing a concrete class doesn't make much sense. = =A0It > >>>>is important to distinguish between: > > >>>>a) state machine "type", which refers to interface definition (of > >>>>method signatures as well as contracted behaviours); and > > >>>>b) =A0state machine "implementation". > > >>>>Class hierarchies confuse this distinction by defining both at the > >>>>same time. =A0That being said I'm not too surprised that it's common > >>>>practise. =A0Separating type and implementation can make for a lot of > >>>>repetition. =A0In a language like C++ it also tends to defeat inlinin= g. > > >>>Limiting inheritance to just interface inheritance, even from concrete > >>>classes, would solve that nicely. > > >>Huh? What the hell does an implementation feature have to do with > >>databases or theory or types? > > > The conflation of fundamental concepts in OO classes causes the > > persistent confusion about types that is evident among OO > > programmers. =A0I believe this is relevant in a group where types are a > > central theme. =A0Anyway, I think this branch of the conversation is > > just about done. > > What makes you think OO classes are relevant in the first place? OO classes are believed and used to model types. Furthermore, the original article about O/R mapping clearly showed the consequences of a lack of understanding of fundamental concepts. "Relational databases" are often blamed for these problems. By understanding the problems and limits of OO classes, the nonsense about OODBMS can be countered.