Обсуждение: warning missing
I think a warning is missing if I create a table without OIDS that inherits from a table with oids: kalman=# create table test ( a integer ); CREATE TABLE kalman=# create table test_2 ( b integer ) inherits (test) without oids; CREATE TABLE kalman=# select oid from test_2; oid ----- (0 rows) don't you think a warning shall to be raised here ? Regards Gaetano Mendola
Gaetano Mendola <mendola@bigfoot.com> writes:
> I think a warning is missing if I create a table without OIDS that
> inherits from a table with oids:
> don't you think a warning shall to be raised here ?
Nope ... this is not different from the behavior for merging duplicate
column definitions. You get an OID column if the child table definition
*or* any parent table requests OIDs.
regards, tom lane
Tom Lane wrote: > Gaetano Mendola <mendola@bigfoot.com> writes: > >>I think a warning is missing if I create a table without OIDS that >>inherits from a table with oids: > > >>don't you think a warning shall to be raised here ? > > > Nope ... this is not different from the behavior for merging duplicate > column definitions. You get an OID column if the child table definition > *or* any parent table requests OIDs. Mmm, you are not convincing me, don't we break the principle of minor surprise? I mean if you duplicate a column name that column is present on the inherited table, but if I say: I don't want the column OID and I found it, this then surprise me. Regards Gaetano Mendola
"Gaetano Mendola" <mendola@bigfoot.com> writes: > Tom Lane wrote: > > > Gaetano Mendola <mendola@bigfoot.com> writes: > > > >>I think a warning is missing if I create a table without OIDS that > >>inherits from a table with oids: > > > > > >>don't you think a warning shall to be raised here ? > > > > > > Nope ... this is not different from the behavior for merging duplicate > > column definitions. You get an OID column if the child table definition > > *or* any parent table requests OIDs. > > Mmm, you are not convincing me, don't we break the principle of minor surprise? > > I mean if you duplicate a column name that column is present on the inherited > table, but if I say: I don't want the column OID and I found it, this then > surprise me. > Speaking in generic OO terms, using inheritance, you cannot remove attributes that are present in the generalisation. If B inherits A, an instance of B is per definition also an instance of A. Thus, you must alwasy be able to cast a B into an A. In short, If you don't want the OID, you cannot inherit a something that has an OID. Having said that, I think a warning is motivated. The warning should state that attributes (columns) present in the generalisation (the parent table) cannot be hidden. Kind regards, Thomas Hallgren
Thomas Hallgren wrote:
>
> Speaking in generic OO terms, using inheritance, you cannot remove
> attributes that are present in the generalisation. If B inherits A, an
> instance of B is per definition also an instance of A. Thus, you must alwasy
> be able to cast a B into an A. In short, If you don't want the OID, you
> cannot inherit a something that has an OID.
This is not completely true:
struct B
{ void foo();
};
class D : public B
{ private: void foo();
public: void bar();
};
as you can see a D "is a" B but the publich foo() doesn't
appartaint to D, at least an user of D could not use foo()
> Having said that, I think a warning is motivated. The warning should state
> that attributes (columns) present in the generalisation (the parent table)
> cannot be hidden.
Right.
Regards
Gaetano Mendola
Gaetano Mendola wrote:
> Thomas Hallgren wrote:
>
>>
>> Speaking in generic OO terms, using inheritance, you cannot remove
>> attributes that are present in the generalisation. If B inherits A, an
>> instance of B is per definition also an instance of A. Thus, you must
>> alwasy
>> be able to cast a B into an A. In short, If you don't want the OID, you
>> cannot inherit a something that has an OID.
>
>
> This is not completely true:
>
> struct B
> {
> void foo();
> };
>
>
> class D : public B
> {
> private:
> void foo();
>
> public:
> void bar();
> };
>
>
> as you can see a D "is a" B but the publich foo() doesn't
> appartaint to D, at least an user of D could not use foo()
>
C++ is not exactly the model for OO semantics. It's a fairly wierd
addition to C resulting in a hybrid language where quite a few
constructs violates sane OO. Try to use a similar construct in a more
elaborate OO-language (like Java, C#, etc.) and you will get an error like:
"foo() in D cannot override foo() in B; attempting to assign weaker
access privileges; was public"
which makes a lot more sense.
Kind regards,
Thomas Hallgren
PS. This discussion doesn't really belong here. I'd be happy to continue
it off the list though.
Thomas Hallgren <thhal@mailblocks.com> writes: > Try to use a similar construct in a more elaborate OO-language (like Java, C#, > etc.) and you will get an error like: Just as a point of reference, Java and C# are not "more elaborate" object systems. For Java at least being *less* elaborate was an explicit design goal. The designers thought C++ had too many features and gave programmers too much rope to hang themselves. They thought by removing major OO features that confuse people the resulting language would be 90% as functional with 10% of the problems. If you want a *more* elaborate OO language than C++ you would have to go to, say, Common Lisp. But I doubt it would support your argument. Common Lisp goes pretty far out of its way to make sure you can do whatever you dream of under the sun. In any case it would make a weak argument given the slim portion of programmers that know Common Lisp. -- greg
"Greg Stark" <gsstark@mit.edu> wrote in message news:87smcl7fdj.fsf@stark.xeocode.com... > > Thomas Hallgren <thhal@mailblocks.com> writes: > > > Try to use a similar construct in a more elaborate OO-language (like Java, C#, > > etc.) and you will get an error like: > > Just as a point of reference, Java and C# are not "more elaborate" object > systems. For Java at least being *less* elaborate was an explicit design goal. > I mean more elaborate from a n OO semantics standpoint. I.e. it enforces OO much more, provides better data hiding, the ability to use interfaces (and thereby enforce interface/implementation separation), package protection, etc. etc. To elaborate something doesn't necessarily mean adding more kludges to a language. > The designers thought C++ had too many features and gave programmers too much > rope to hang themselves. They thought by removing major OO features that > confuse people the resulting language would be 90% as functional with 10% of > the problems. > > If you want a *more* elaborate OO language than C++ you would have to go to, > say, Common Lisp. But I doubt it would support your argument. > I'm not an expert on Common Lisp but I think it would. At least if you'd use CLOS and defclass. There's no way to hide readers/writers/accessors that you inherit. From an OO semantics point of view, I still regard Java and C# much more elaborate than both C++ and Common Lisp. The latter lacks interfaces and different levels of protection. Kind regards, Thomas Hallgren
"Thomas Hallgren" <thhal@mailblocks.com> writes: > From an OO semantics point of view, I still regard Java and C# much more > elaborate than both C++ and Common Lisp. The latter lacks interfaces and > different levels of protection. It doesn't "lack" interfaces. It has actual multiple inheritance. Which is what interfaces are there to substitute for. -- greg
"Greg Stark" <gsstark@mit.edu> wrote in message news:87659h6rri.fsf@stark.xeocode.com... > > "Thomas Hallgren" <thhal@mailblocks.com> writes: > > > From an OO semantics point of view, I still regard Java and C# much more > > elaborate than both C++ and Common Lisp. The latter lacks interfaces and > > different levels of protection. > > It doesn't "lack" interfaces. It has actual multiple inheritance. Which is > what interfaces are there to substitute for. > Yes, it does lack interfaces and no, interfaces are definitely *not* a substitute for multiple inheritance. An interface is a contract and behind that contract you may have several different implementations. JDBC is a good example. PostgreSQL has a JDBC driver. So do most other database vendors. The thing they have in common is that they implement a set of interfaces that together constitutes a contract stipulated by a version of JDBC. I think we are drifting far apart from the actual subject now. Wether or not Common Lisp has interfaces seems somewhat irrelevant to the original question. Kind regards, Thomas Hallgren
"Thomas Hallgren" <thhal@mailblocks.com> writes: > Yes, it does lack interfaces and no, interfaces are definitely *not* a > substitute for multiple inheritance. I assure you that interfaces were put into Java specifically as a substitute for full-blown multiple inheritance. The normal way to describe interfaces to a new Java programmer familiar with OOP is "Java supports a limited multiple inheritance where all but one parent class must be abstract" (Though even that isn't true with "default implementations" for interfaces now. Now you basically have full-blown multiple inheritance with a quirky syntax.) > An interface is a contract and behind that contract you may have several > different implementations. JDBC is a good example. PostgreSQL has a JDBC > driver. So do most other database vendors. The thing they have in common is > that they implement a set of interfaces that together constitutes a contract > stipulated by a version of JDBC. This is a standard technique for other OOP languages as well where you define an abstract class that defines your API. Any implementation declares itself as a child of that abstract class in addition to whatever hierachy it would normally lie in. > I think we are drifting far apart from the actual subject now. Wether or not > Common Lisp has interfaces seems somewhat irrelevant to the original > question. Well the original question is was whether Java was a "more elaborate" OO language or a more kludgy half-measure. That interfaces are specifically intended to be a half-measure to substitute for the full blown OOP feature that the designers thought was too confusing is a good example. In general though the design goal for Java was to cherry pick the most useful features of OOP languages and leave out the features the designers thought were more dangerous. Whatever the merits of that approach, it certainly doesn't qualify as the paragon of OOP languages. The fact that it doesn't allow a certain usage as far as access privileges could be because it was a good OOP design idea but it could also simply be because the designers just thought that implementing the more "correct" model would be too complex or too confusing for beginner programmers. Furthermore the situation is further complicated by Java's complex security model. Since Java was designed with network security in mind there are some things it cannot support. Not because the programming model is a bad idea, but because it would lead to security violations in a network environment. I'm not trying to rag on Java here. (I do that elsewhere:) I just wanted to point out that using it as an example of how OOP design methodology works only goes so far. It's a particularly poor example when you're arguing that other languages are lacking for allowing something Java disallows. -- greg
Greg, You don't like Java/C#. I do. There's not much point arguing about it. You feel that abstract classes are equivalent to interfaces provided you have multiple inheritance, I don't since I'm in favor of a totally clean interface/implementation separation. Now you bring in the Java security model. We could of course discuss that and I could argue that MI was rejected for other reasons then the one you mention. But I don't think that's going to lead anywhere. If you feel that C++ and/or Common Lisp is a better OO language then Java and C#, then for you it certanly is. For me it's not. Let's just respect eachothers standpoint and end the discussion here. Kind regards, Thomas Hallgren
Thomas Hallgren wrote: > Greg, > > You don't like Java/C#. I do. What appear here is that you hate C++. I'm a C++ developer since long time now, and I can not use JAVA and or C# just for a couple of reason: 1) Java was supposed to be platform compatible: in thereality is not really true. 2) I can not use the RAII Idiom, or at least without be a joggler 3) I miss the "const" modifier for methods, and I really can not be sure of what happen to my objects when are used around. Do you want now speak about the missing template feature? Don't say template are the same of Generics. Regards Gaetano Mendola
Hello, You all are behind... Python is king. Sincerely, Joshua D. Drake Gaetano Mendola wrote: > Thomas Hallgren wrote: > >> Greg, >> >> You don't like Java/C#. I do. > > > What appear here is that you hate C++. > > I'm a C++ developer since long time now, and I can not use JAVA and or C# > just for a couple of reason: > > 1) Java was supposed to be platform compatible: in thereality is not > really true. > 2) I can not use the RAII Idiom, or at least without be a joggler > 3) I miss the "const" modifier for methods, and I really can not be sure > of what > happen to my objects when are used around. > > Do you want now speak about the missing template feature? Don't say > template > are the same of Generics. > > > > Regards > Gaetano Mendola > > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL
Вложения
Joshua D. Drake wrote: > Hello, > > You all are behind... Python is king. Just to throw more fuel on the fire. Relvar inheritance is, according to Chris Date, one of the two Great Blunders in database engineering over the past twenty years. Multiple Domain Inheritance: Yes Relation Variable Inheritance: No I think it'd be a fair statement that Date & Darwen would have the relvar inheritance ripped out of PostgreSQL as an experiment gone bad... Mike Mascari P.S.: D is the language of the future: http://www.digitalmars.com/d Ha!
Gaetano, I've been using C++ for 15 years and Java for 7. I like them both. Every language has its pros and cons. C++ can be extremely powerful in the hands of someone who knows how to use it. I actually wrote the first version of Pl/Java in C++. However, I got strong advice to rewrite it using plain C (which I did) to get maximum acceptance. Kind regards, Thomas Hallgren
Gaetano Mendola wrote: > Tom Lane wrote: > >> Gaetano Mendola <mendola@bigfoot.com> writes: >> >>> I think a warning is missing if I create a table without OIDS that >>> inherits from a table with oids: >> >> >> >>> don't you think a warning shall to be raised here ? >> >> >> >> Nope ... this is not different from the behavior for merging duplicate >> column definitions. You get an OID column if the child table definition >> *or* any parent table requests OIDs. > > > Mmm, you are not convincing me, don't we break the principle of minor > surprise? > > I mean if you duplicate a column name that column is present on the > inherited > table, but if I say: I don't want the column OID and I found it, this then > surprise me. Peter, what do you think about it ? Regards Gaetano Mendola