On 22 Oct 2005 at 23:29, Waldek Hebisch wrote:
Prof A Olowofoyeku (The African Chief) wrote:
On 22 Oct 2005 at 20:06, Waldek Hebisch wrote:
<snip>
Compile and run this with BP, and you get garbage. With FPC, you get a warning at compile time, and a runtime error at runtime. With Virtual Pascal, you get a runtime error at runtime. Add and call a constructor, and the problem goes away.
So, a warning is not a bad idea (better than a crashing program).
Maybe I was not clear: I do not want to change how BP objects behave, so the warning for BP objects will stay in place. But I see no need for such warning in other models.
Ok. I did misunderstand you.
I think you misunderstood me. In Delphi mode, "TObject" should be the implicit ancestor of all classes, and in OOE mode, "Root" should fill this role. This should not be susceptible to being overridden by a command line switch.
But this will be susceptible to being overridden: you choose model using command line switch and then override any other aspect of the model so only the choice of base object remains.
True. In that case, I think there should be a default mode when "Class" is used. If you have "Type foo = Class" - does that mean an OOE class or a Delphi class? I suggest that, by default, it should mean a Delphi class (e.g., if no class dialect is supplied at the command line).
Of course, we can limit choice to none, "Root" or "TObject". Also, having to give a long chain of options will somewhat reduce abuse.
Since "Class" should (IMHO) mean an OOE or a Delphi class, I think the choices should be between "TObject" (default) or "Root". If the answer is "none" or something else, then "Class" in that case does not refer to a Delphi or OOE class, because it would be incompatible with both of them. Should this be allowed? I think not. It is one thing to support classes and objects that conform to one or other standard, and it is quite another thing to support those that conform to no known standard.
The other variants also have drawbacks, that is why I would prefer to leave the choice to programmers.
Yes, the programmers should have the choice - but the question is whether that choice should be exercised in code or at the command line. With regard to default ancestors, I think it would be problematic and error-prone to change default ancestors at the command line.
The point here is to minimize impact on existing code -- if a programmer have to change the code then she has no choice.
True.
I agree that playing with default ancestors may lead to weird errors. But I am affraid that sometimes it may be necessary. So we need to find good balance.
Agreed - if limited as suggested above.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/