Rudy Velthuis

I know there is a way to mark an entire forum as read, but is there a way to mark a single thread in a forum as read too? Marking an entire forum as read is a little drastic, IMO, but marking a thread (i.e. all messages currently in that thread) as read would make a lot of sense, IMO.

I'm pretty sure that some of the groups accessible in Google Groups are actually Usenet groups. AFAIK content posted on such a group in Google Groups will be propagated to Usenet too. Content posted to Usenet will appear in the corresponding group in Google Groups too. Could be that they blocked certain spam-infested newsgroups, though.

Which is weird, since AFAIK they started out as NNTP Usenet groups. But I assume they did not moderate or not enough. OTOH, it seems they still do NNTP, according to Wikipedia: https://en.wikipedia.org/wiki/Google_Groups Spam can be a problem. I know from the Borland and Embarcadero groups. There were days when I cancelled several thousands of spam messages in one group. Fortunately, with XanaNews in the TeamB mode, it was quite easy to do that.

Yes, that would be what I meant. But the fluent layout is a little too fluent for me.

Is the entire thread marked as read when I enter it? Or just those parts I can see (first page, second page, etc.)? I admit I didn't think of that. This is different from NNTP, indeed, where you had a tree view on all messages and you selected only one for reading (still my preference, sigh). Here, when you open a thread, you see the whole bunch, inlined. I never liked that in Java or C#, and I don't like it when reading messages either. Can't they make a web forum that at least behaves a little like NNTP? With proper threading? Didn't Google have something like it?

These differences have absolutely no effect in a C++ loop. The increment is considered to be the last line in the (while) loop, and on a line alone, nor i++ nor ++i make a difference.

That was not a thread in a forum, that was a feature request in the bug report system, Quality Portal. Marco made a comment that (at that time) he saw no good reason to pull a stable compiler apart for it. The request for inline variable declarations etc. p.p. was closed for a long time, until it was opened again recently and the features were finally implemented in 10.3 Rio.

RAII is for things that must be reversed, i.e. pointers that must be freed/deleted, screen cursors that must be returned to crArrow, files or ports or streams that must be closed again, etc.etc. But many objects in C++ are not used from a pointer or reference (except if they are supposed to be inheritance-polymorphic), they are used as stack (local frame) objects. That is the main automatic memory management. Actually RAII also builds on that principle: the reversals are done in the destructors of the stack-based RAII objects. And C++ has had from the beginning what Delphi got now too: limited scopes, i.e. variables that live only during the scope of a block, not just an entire function frame anymore. Together with mrecords with automatic destruction (you don't even really need automatic construction for that, IMO), that provides a simple way to do RAII too, one that does not involve interfaces and is probably far more lightweight and faster than the current smart pointers/guards/whatever using interfaces. But even with interfaces: an interface declared as inline variable must be released at the end of the block in which it was declared, not just at the end of the enclosing function anymore.

You never proved he was against them. Just that he did not see the need at that time and that he did not see a good reason to make such a change to the language. He said And he was right: there was no good reason, there and then. But, as I already said, there was one now. This (inline, block local variables with type inference) is, as far as I can see, just the first part of a larger plan, which also involves mrecords and probably even a bit more. People have also said I was against a Win64 compiler. I have never been against it. I have always argued that at that time, i.e. when some, few people wanted it right there and then, it did not make any business sense yet. People interpreting other people's words in their own, wrong way and then perpetuating their wrong perception has often been the cause of a lot of trouble.

I just found out there is a limit to the number of reactions like "Thanks" or "+1". Where can I find what this limit is, and why does it exist? Are there more limits like this? Number of posts per day/thread/whatever?

I think "Sad" is negative. But I guess you mean something like a downvote. <g>

Thanks for raising the limit. 10 was a little low, indeed. After all, reactions do not interrupt the flow of the "thread" or somehow interfere. I actually assume that most posters are glad about such reactions.

They make a lot of sense together with the conceived mrecords. I guess that is the main reason they are introduced now. Mrecords are default constructed at the time they are declared, and destroyed at the end of a scope, so it makes sense that now, you can have blocks with inlined block-local variables that are default destroyed a the end of the block (or loop). IOW, it seems to me that inlined, block local variables are part of a larger policy that is not fully implemented yet. Type inference belongs to inlined variables, so people got what they want. After all, we already had some limited type inference for constants and generics already.

In a company like Embarcadero, they are never made by one person alone. That the RSP was closed did not mean they would never do it Just that at that time, it was not necessary. But it actually makes a lot of sense right now, in the context of mrecords (i.e. those with default constructors etc). We didn't get those yet, but we got the inlined the variables. With inlined variables, and local block scopes, mrecords can be default constructed and more importantly, default destroyed, in a single block, just by declaring them inline in such a block, or in a loop context. In and of themselves, they still do not make a lot of business sense, IMO. They are nice to have, but not absolutely necessary. Only together with mrecords, they start to make sense. They changed some other policies, e.g. the use of ARC on Linux or the exclusion of 8-bit strings (Utf8Sring, RawByteString) in mobile. I doubt they will ever reverse their decision about slowy phasing out ARC, because that was a reversal already.

Then why do you complain about my dismissal? I can't dismiss anything here. The people at Embarcadero can, and I do think they know the compiler better than you do, and the language and all the relevant issues too, no matter what you think. And they are the only ones you must convince. No one else here can do what you want. Only they can. Telling them they are more or less stupid or ignorant about their own product is not the best way to achieve anything from them.

There you go again. On the Embarcadero server, I would have already cancelled that message and suspended your access for a few days. You obviously can't discuss without being insulting.

Was he? Not as far as I know. EOM.

Haha, funny. But I'd rather know about the number of daily "reactions" like "Like", "Sad", "Thanks", "Confused" or, indeed "Haha".

I am saying they will certainly dismiss it. You don't have to convince me, as I don't decide such things.

It is quite a bit to claim you only know the truth and the people at Embarcadero don't. But aside from that, it is futile to argue how it shall be done if it is sure it will never be done. That is truth. And now I'm probably finished with the topic.

I will not repeat my arguments. I have already shown what is wrong with yours. You know my view, you know the view of the people responsible art Embarcadero. Your efforts to "convince" them are futile, both because of your bad arguments and because of your behaviour. And it is not even sure they will ever read this. This is not an official outlet of Embarcadero. That can be found here: https://community.idera.com/developer-tools/p/forums

If every container or function taking objects as parameters must be done twice, then that is some kind of Apartheid, instead of easy co-existence. And you claimed there would be easy co-existence. I assume you know what Marco Cantù wrote, and that that probably is the opinion of the entire Delphi team (http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html): That is exactly what I am saying, and you have proven it a few times now. I have shown that you must either separate containers and functions, or that you must add explicit runtime code to everything that allows you to mix such objects, i.e. there is an added runtime cost (and not just at compile-time, as you claimed). If you add that, no matter how you implement it, even if it is only as a flag, there is a runtime cost too, then it is clear that this is not a viable solution. It is kludgy, it requires a lot of code duplication, it slows things down and it is confusing. I am very much in favour of finding a way to make lifetime management of objects easier, and ARC would be one way, but mixing ARC and non-ARC is not a viable one. Also, the move back to non-ARC was done for simplicity and speed and to finally get back to one object model for all platforms. You would lose these advantages with your mixing model. So you can talk about it a little more, but I am sure that neither your attitude nor your arguments are helpful in convincing them. In other words: I am pretty sure what you want will never be done. Perhaps you can convince the FPC people to implement it for you (although I guess they would refuse that too, for similar and probably for some more reasons), or you can try to find a group of people who fork FPC and then implement if for you. Good luck. I have said what there is to be said. I agree with the Delphi team and I am pretty sure they had the same insight and reasons as I had.

Is there another UI?

I am pretty glad about the Pascal for loop(s) (i.e. for-to/for-downto and for-in), because they have the advantage that, in the case of for-to/for-downto, the end index is fixed, and that it only needs to check an index, not any general condition. But a loop like the C for-loop would be nice to have additionally. It should just be called differently, e.g. loop: loop i := 10; i < 20; Inc(i) do Unfortunately, Delphi does not have a comma operator, so you probably couldn't do: loop read := 0, write := 0; read < Length(s); Inc(read) do Although, with that syntax (commas and semicolons as separators) and some extra clever logic in the compiler, it could perhaps even be called for too. It should of course also know type inference and local inline declaration of variables, like the current for loops in Delphi.

Yes, I saw that there is no chance we'll see an NNTP version of these forums, but I just wanted to say that IMO no online forums, no matter how well they are done, can ever beat NNTP. NNTP is just content and everything else, i.e. navigation, layout, font, markup, colouring by content, threading, etc. can be decided by you by simply choosing the newsreader of your choice and configuring it the way you like. Compared to that, online forums are like straightjackets that leave not much room for movement, nor any proper tree-like threading. I still fail to see why TPTB at Embarcadero abandoned NNTP.