OOP_(re)

Tue, 27 May 1997 15:30:44 -0400 (EDT)

On Tue, 27 May 1997, The African Chief wrote:

> It would be nice if your classlib could build on the object heirarchy
> in BPCOMPAT, instead of introducing a completely new one (at least,
> if all your main "PierreObject" is a descendant of TObject). This 
> would ensure some continuity. You could amend TObject if necessary,
> so that it would meet your needs as the ultimate ancestor of your
> own objects. All that is necessary is to ensure that programs written to 
> use TObject as it currently is (which would be very few indeed) are not
> broken, which will be a trivial thing to do.

Hmm... I could try to, but the design is a tad different... Personally, I
see the BPCOMPAT object heirarchy only as a tool to make BP programs
compile, not as a library to write programs from scratch with it. I have
my own container classes, enhanced streams, filters (an addition to
streams which is very useful), and other things...

> Also, when implementing your new TV stuff, it would be nice to make it
> more friendly. I find Borland's TV quite incomprehensible - it is as if it
> wasn't made by the same company that made OWL (which I find to be
> easier to deal with). But perhaps it is because I lost patience with TV
> very quickly.

It is not exactly "TV stuff"... I plan to build a user interface later on,
but for now, I only want to provide basic components for an OO
application. I don't know yet what the design of this UI will be like, but
rest assured it won't bear much resemblance with TV... ;-)

> >Yes, I agree, but let's keep in mind what we're looking to fix in this
> >thread is the BPCOMPAT package, which will have to look like BP libraries
> >are, at least on the outside. 
> 
> I think that this is crux of the matter. We are trying to produce a package
> that will allow GPC to compile BP programs (i.e., the external interface is 
> similar to that of BP). We  are not concerned to ensure that the internal 
> implementation is identical to that of BP (unwanted side effects aside). 
> We are also not concerned to ensure that the code will compile under BP 
> itself. Much of the current BPCOMPAT will not compile under BP, because 
> of the use of functions from the C library, and the use of EP initialization 
> and finalization stuff. So, please let us not hamstring ourselves by trying 
> only to write code that will also compile under BP. Eventually, BP will go
> the way of the dodo - GPC is the way forward! 

Exactly, that's why I don't think much enhancement are needed regarding
BPCOMPAT. I looked at your TObject, and what I thought was that there was
many fields that aren't there in BP, much more than I thought for a BP
compatibility unit... ;-) I think those are for Delphi compatibility, am I
right? I'm not sure we should pursue Delphi compatibility... Or maybe if
we do, have it separated from the BP stuff. They are just sufficiently
incompatible to breed trouble... Like those "Parent" variables in Delphi,
they are implemented by the *compiler*, not the libraries! They are
present in each and every objects, even if not descended from TObject!

> Personally, it seemed too tedious to write any useful code. Felt like
> it was a classlib written by a sadist or a masochist, or both ;-). 
> However, some people feel that way about OWL too - and I personally
> prefer OWL to TV or even to Delphi's VCL.

I think there was too much inheriting to do. You had to inherit a
TApplication for your application, and you had to inherit every class you
wanted to have handle messages... Tedious at best, yes.

> >As for the class registration, what I didn't like was that it used the
> >data segment, which isn't a very clean hack IMHO... Apart from that, it's
> >ok by me (the class registration system!). The Free method is one of the
> >purest evils in there. :-) (and it is in the BPCOMPAT package!)
> 
> Well, Free() was included just because Borland included it (i.e., "external"
> compatibility).

And I agree with it! It *should* be in BPCOMPAT! But you can be damned
sure my library *doesn't*!!! ;-)

> >I'm developing something here for a "GPC enhanced" class library, I'll
> >keep you posted! 
> 
> That would be great. Which objects are you thinking of including? Are
> you tailoring it after [a] TV (eek!!); [b] OWL (:-)); [b] VCL ( !!); [d]
> OPRO (;-/);  [e] something else ? 

[e].

Pierre Phaneuf

"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." - Edsger W. Dijkstra.

Pierre Phaneuf (pp@dilu.ml.org)