David Heffernan

No. It is deterministic.

Those are two completely different things. One is a generic dynamic array type, the other is a generic method.

You are just polluting the namespace for no benefit. Use TArray<T>.

D is a truly wonderful language, and Andrei Alexandrescu's book is by some distance the best programming book I have ever read.

Basically this then?

So, is it the case that rtti is generated for types declared in the project file, but these rtti types don't have a qualified name?

I don't think about you at all. I was interested in the question. Try to view comments as impersonal. That's entirely possible. I'm interested in learning. It's possible that my misunderstanding is because of imprecise statements. It's possible I'm slow on the uptake. To be clear, I thought you said that types declared in the project file had no RTTI. I checked that and was able to retrieve RTTI for such types. I simply don't understand the strength of your reaction.

My post above demonstrates that RTTI does exist. I think that the real issue is that these types don't have qualified names.

program Project1; {$APPTYPE CONSOLE} uses System.SysUtils, System.Rtti; type TMyClass = class public procedure Foo; end; procedure TMyClass.Foo; begin end; procedure Main; var ctx: TRttiContext; Method: TRttiMethod; begin Method := ctx.GetType(TMyClass).GetMethod('Foo'); Writeln(Method.Name); Writeln(Format('%p', [Method.CodeAddress])); end; begin try Main; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; Readln; end. This demonstrates that what you said is not correct.

That's what I mean. Obviously if somebody finds a bug, whoever it is, that's good.

Beta testing is no substitute for having your own comprehensive set of automated tests. Beta testing is best used to help identify issues with design. It really shouldn't be used to find implementation bugs. I hope that Emba don't do that. When Emba tell us that they are going to focus on quality, it comes with talk of how many QP issues have been resolved. But for me that misses the point. Unless they are also fixing the development process that allows so many bugs, they will remain stuck on the treadmill, running to stay still.

RTTI is available for all types, be they public (interface section), or private (implementation section or project file).

It just goes to show how easy it can be to misinterpret what people mean.

I don't think there's any point in picking up those things. I mean edit a post to resolve them, but no need to comment on them. You pay your doctor for a service. Stack Overflow is a little bit different. I have utterly no influence on Stack Overflow.

That's a valid choice. If you don't agree with the site's policies, then you can choose not to use it. There is too much of that going on, I agree.

It came across as patronising and gleeful. I don't agree with that. I think anyone who says that doesn't understand Stack Overflow in the round. There's a huge problem with Stack Overflow, but it's not what you allude to. In the beginning the site had very little content and there was a void to be filled by asking questions. After some time the majority of questions had been asked and answered. The overwhelming use of the site is a websearch that leads to topic on the site with an existing question that matches the user's needs. Overwhelmingly users get their answers without asking new questions. Nowadays there are basically two main form for new questions that get asked 1. A question is asked that has been asked before. These get closed as duplicates. 2. A question is asked by a user that has done no debugging. Closing duplicates is good for everyone. The other form of question has no real value. You can answer the question and the asker learns nothing. Or you can try to help the user learn the value of debugging and so be able to do it for themselves in the future. The site doesn't really make it easy to do this, but i firmly believe it's the right thing to do. As is well known I've spent a lot of time on Stack Overflow over the years. These days I spend very little time there, because interesting questions are so rare. I think perhaps I have a very different perspective of the site than you do given the very different ways that we use them. I think this is an interesting topic, but it's not the topic that this thread is covering. If you want to discuss Stack Overflow, then that would be better in a different thread.

Surely all full time delphi programmers would be ecstatic with this.

This is what you mean by friendliness, respect, tact is it? Perhaps I'm missing the point.

Interesting contribution. Thanks.

He means that the difference in performance is so small as to be unimportant to him

I didn't mean to show you any disrespect. I'm sorry that it came across that way. All I meant was that I thought the argument that compilation speed was important was bogus. I really did not mean to upset you. I try hard never to make anything I write personal. To me it's always about the technical details.

I don't think that anybody here has used a straw man. And only two people have made any statements directed at an individual, rather than concentrating on the arguments.

Compilation time is not a valid reason to make that choice. I stand by that. Your own measurements backed up my point of view. It wasn't. I understand that, but there's no good reason why they shouldn't have the same relative characteristics. So whilst the x64 compiler may well be slower than x86, the x64 compiler should not blow up when presented with huge numbers of typed constants, in a way that the x86 compiler does not. A more plausible explanation to me is simply the history of writeable typed constants. At this point we all know what each other thinks, and there's little point repeating ourselves any more.

The biggest issue with constants in Delphi are that typed constants can't be used in certain settings which require true constants to be used. The ones that come to mind are: 1. When declaring typed constants. 2. When declaring attributes. The inability to used typed constants in these settings is clear weakness in the language. There are probably more issues, but these are the ones that bite me. I'm tired of hearing justification for these limitations based on the current implementation. All this talk about single pass, interface vs implementation, writeable typed constants, etc. If the implementation limits you, change it.

A few milliseconds during a typical compilation is insignificant. That's my opinion. Others may have a different opinion. They are welcome to it.