Prof A Olowofoyeku (The African Chief) wrote:
[...]
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.
So why not try to design a clean way? The best solution to me so far seems be a utility that is run before compilation that scans the source code for dynamic methods and creates the `case' statement. This would be completely external of GPC, BTW.
If you have any other ideas for a clean way, we can discuss them.
If the former is chosen, then one might as well not bother trying to implement the feature. This is a supposedly BP- compatible feature
Not only supposedly. As it is now, ignoring the index, it is compatible to the documented BP behaviour, let's not forget this.
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).
Perhaps you can find someone to look at it and just describe this particular thing (in words, of course, not copying the code).
Actually, this might be an interesting point: If we implement some compatible feature by reading the documentation and finding out ourselves how to implement it, that's a clean reimplementation, AFAIK. But if it requires looking at their source code to find out what some feature does at all, we must be very careful not to get into copyright problems ...
[...]
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.
I hold that it's not relevant *how* they did it, but *what* the feature actually achieves. E.g., if we'd decide to implement such a dispatcher with a faster binary search or a table lookup (compared to the linear search that BP probably uses), that would still be compatible.
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.
It really doesn't take much hindsight. Whenever type-casts are needed (whether in the library or in the, perhaps hidden, dispatcher), that's an indication that there might be a design problem. (Which is not to say that I never use type-casts myself, but when I do, I'm well aware that what I do is probably not the best thing possible.)
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.
Yes -- because these are often quite bad choices (in many of those things we've discussed -- of course, there are other ones, but most of them have been implemented some time ago with much discussion; naturally, it's the controversial areas that cause most discussion).
Note that I haven't said I dislike this feature just because it's Borland's. I gave some concrete arguments which have not been rebutted.
When I started the discussion, I wasn't aware of these issues. I thought it was a trivial thing to do. Now at least I know there's more to it.
I've done the easy thing (i.e., the documented behaviour) now, and put the other thing back on the to-do list.
Frank