On Mon, 26 May 1997 20:09:51 -0400 (EDT) Pierre Phaneuf pp@dilu.ml.org wrote:
On Mon, 26 May 1997, Frank Heckenbach wrote:
Bottom line: I don't think it can be done all automatically, but it can be done much more comfortably to the programmer than in TV.
I agree with you. I am in effect creating a better way to do it, but it will NOT be in BPCOMPAT. I'm a proficient user of TV, and I'll try to have the object parts of the BPCOMPAT package as compatible with it as possible... It *will* be in a GPC-specific class library of mine I'll contribute to the GPC team "When It's Ready (TM)", of course! ;-)
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.
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.
[...]
We are in part. The primary goal of GPC is to produce the best Pascal compiler the world has ever seen.
I agree with Peter. I, FWIW, didn't use TV -- partly because some parts of it (including class registration) were, IMHO, badly implemented. If gpc's TV would be the same, I probably wouldn't use it, either.
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!
BTW, what didn't you like exactly with TV?
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.
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).
So we may need both: a "100% BP compatible" unit for quick changes, and a "better" gpc unit to which programs can be converted afterwards, and which new programs can use from the beginning. Actually, I think, the changes needed for BP programs shouldn't be too big: make the "Load" constructor virtual (if we do it this way), declare the "ObjID" constant, and remove the registration stuff. Could even be simplified with some "IFDEF"s and clever use of the preprocessor, I guess.
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 ?
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra.
Except it can save the world from the Year 2000 fiasco!
Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.50 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12@cc.keele.ac.uk
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 -
The African Chief