Thread: warning missing

warning missing

From
Gaetano Mendola
Date:
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








Re: warning missing

From
Tom Lane
Date:
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


Re: warning missing

From
Gaetano Mendola
Date:
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




Re: warning missing

From
"Thomas Hallgren"
Date:
"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



Re: warning missing

From
Gaetano Mendola
Date:
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





Re: warning missing

From
Thomas Hallgren
Date:
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.



Re: warning missing

From
Greg Stark
Date:
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



Re: warning missing

From
"Thomas Hallgren"
Date:
"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



Re: warning missing

From
Greg Stark
Date:
"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



Re: warning missing

From
"Thomas Hallgren"
Date:
"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



Re: warning missing

From
Greg Stark
Date:
"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



Re: warning missing

From
Thomas Hallgren
Date:
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




Re: warning missing

From
Gaetano Mendola
Date:
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




Re: warning missing

From
"Joshua D. Drake"
Date:
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

Attachment

Re: warning missing

From
Mike Mascari
Date:
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!




Re: warning missing

From
"Thomas Hallgren"
Date:
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



Re: warning missing

From
Gaetano Mendola
Date:
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