On 26 Apr 2003 at 18:42, Frank Heckenbach wrote:
[...]
Seriously, when discussing the merits of some feature, we must at least consider it concretely. Just saying someone may be able to do something with it is pointless.
I think I have already stated what *I* would like to do with it, and why. The reason why my OWL-compatible framework is not really OWL- compatible is because I could not produce a compatible dispatch mechanism for dynamic methods, but had to use case statements. Thus the solution which you espouse adds nothing to what I am trying to do, since that is the one I already use - and it is not OWL-compatible. Whether the OWL mechanism is good or not is not the point when the goal is to produce a framework that is compatible with it. Implementing dynamic methods wherein the indices are ignored and cannot be utilised to achieve my goal does not really advance the matter very much (other than avoiding the need to change method declarations in existing OWL code).
[...]
The point is that there is no documented way to retrieve them (at least not AFAIK -- the BP documentation doesn't contain any, and you didn't tell me any so far either).
No, there is no documented way to retrieve them. That just means that we have the freedom to choose. The choices are to provide nothing, or to provide a clean way. If the former is chosen, then one might as well not bother trying to implement the feature. This is a supposedly BP- compatible feature and it is clear that, in BP, there is a way to access the information, even if they chose not to document it (of course anyone with source OWL code will see how they did it - but I cannot let myself look at - it for obvious reasons).
[...]
I hope you understand now why I'm so allergic to this "that's how Borland does it" argument.
No - especially not at the level of a BP-compatible feature. If the aim is to be compatible, then how they did it is relevant. There may be "better" (in someone's opinion) ways of doing it - and we all have the benefit of hindsight so as to be able to avoid pitfalls if possible. fine. Even at the general level of the usefulness of a proposed feature, it is still relevant to discuss how someone else has done it - not for the purpose of following it slavishly, but to show that it can be done and has been done, and then to see if and how it can be done better.
Whether or not to implement a BP-compatible feature is one thing - but once the decision has been made, then implementing a BP-compatible feature that is not really BP-compatible seems odd.
[...]
Apparently they don't mind to create some dead-ends (like so much proprietary software). In contrast, we should try to design our features in a future-proof way, so that they will not force some people to keep using old versions when something changes ...
In this case, there is no dead end at all. OWL can be ported to Delphi without too much pain, and the dispatching mechanism for dynamic methods that we are discussion is already present in Delphi.
In the event, it is up to you what you choose to implement in the compiler. I have nothing further to add to this discussion. It seems that discussions on implementing BP-compatible features often lead to endless and pointless debates that often involve Borland-bashing. Perhaps if you want to implement a new BP-compatible feature, you should just do it however you see fit, instead of inviting comments, since you clearly have very definite views on these things, and you are obviously unimpressed with Borland's choices on how to do them.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/