On Thu, 5 Sep 2002, Jeff Davis wrote: > But a person is-a employee (allow me to momentarily step aside from > the rules of english grammer, if you would), and a person is-a > programmer. That's why I didn't call my table "job" :) [1]
Certainly it's not the case that a person is-a job, by virtue of the fact that a person can have no job. Nor is it the case that a person is-a programmer; not all people are programmers. Perhaps you're reversing the sense of "is-a"? One says "subtype is-a supertype," not "supertype is-a subtype." But even reversing these, it's not the case that job is-a person, by virtue of the fact that you cannot use a job anywhere you can use a person. (A person can file his tax return, a job can't.) That might be a matter of bad mappings of object names to real-world concepts, though. As for "programmer is-a person," yes, you could model things that way if you really wanted to. But it's a bad way to do it because, as you point out, a person can change his job, or not have a job. Now what do you do with that programmer-subtype-of-person object you created? I think in this case English misled you: we do say that "he is a programmer," but what we really mean is that "one of the characteristics of that person is that he programs." So create a separate characteristic type and have the person object "have-a" as many or as few of those characteristics as you need. > I don't like the way some OO programming languages handle objects, if they > mean to say you can't change an object's type without performing a logical > data copy to a new object. That's not a problem with the programming language; that's you modelling things badly. > Take as an example python... it's easy to emulate other objects: just assign > to the attribute, even if it's not there yet, it'll add the attribute. Same > with python, it's providing room to expand for it's objects already, so why > do all the copying? Now compare with Java, and see why you'd be annoyed. It > has the facilities to change the objects all around, but you can't do it. Yes, you can't do it in Java because you Can't Do It in a language where you can specify static typing. If I have field that holds a String, I'm given a guarantee that, if I can put a reference in that field, it is and always will be a String. In non-statically-typed languages that give you the option of changing types, you might give a referenc to a string, change the objects type on me, and then I might blow up when I try to use it later. These bugs tend to be quite difficult to track down because the source and manifestation of the problem can be widely separated in code and in time. That's why most languages don't allow this. > ...when the more obvious logical path is to expand on the data you > already carry about an entity. Yes, that's the perfectly obvious path. And that's just what the relational model lets us do, and do very well. Why do you want to use an ill-fitting, error-prone model when you've already got something that works better? > [1] Come to think of it, the JOIN operator seems to, at least on a first > thought, represent the "has-a" relationship you describe. You bet! Hey, this relational stuff doesn't suck so badly after all, does it? Especially for a 30-year old theory. :-) cjs -- Curt Sampson <[EMAIL PROTECTED]> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
