Rudy Velthuis

Sorry if this has been discussed before, but I can't find it. I have a few questions about using these forums. Is there a way to manage my uploads? I want to remove an image (a screenshot of my desktops) that was inadvertenly uploaded. Is there a way to remove an image from a message? I couldn't find a way. I can delete it, but when I save, it appears again. Is there a way to delete your own messages? Sometimes, when I re-read a post, I see it is obsolete because someone else already covered it. ISTM that these are common functions for a forum. Do they exist or do they require a setup by the admins or can I already do these things myself? Especially the ability to delete your own messages (also after longer than 24 hours) seems crucial to me. Otherwise, I would like the ability to at least edit my messages without a time limit.

I see you're trying to find more friends. <g>

It would not be what I am looking for. I would like to have an option that messages that are read do not show up anymore, or show up greyed out.

I gave one simple one, and that already proved that you were wrong claiming that: the compiler can detect such differences at compile time The objects can easily co-exist Both claims turned out to be wrong. Add to that that although not all objects use ARC, you either have to implement the refcounting methods anyway, and they simple don't do anything, or your code must check at runtime if the objects is ARCed or not (and if not, it doesn't get these methods), simply to find out if addref or release must be called. Both options mean that there is a runtime cost: either the code that calls the nonfunctional refcounting methods, or the code that must check if an object is managed or not. Also note that managed objects can not be treated the same way as non-managed objects WRT casting etc.

In that other, long thread, you already had to admit that that is not true. I gave the example of TMyContainer.Add(A: auto TObject); You said the container would be for ARC only. That showed that you would either need separate containers for ARC and for non-ARC objects or, if you could mix objects in such a container after all, you would need to write explicit runtime code to distinguish them so you would know if you should release or free them, or, if you copied a reference, if references should be counted, etc. You claimed it could be done at compile time, but that is not true if you can mix objects. That shows that your ARCed objects would not easily co-exist with non-ARC objects.

No, you don't need reference counting. Refcounting is just one of the possible ways to avoid lifetime issues (memory management is actually not the problem, for that we have a memory manager; lifetime management of objects is the problem). Delphi already employs several different ways to do (automatic or semi-automatic) lifetime management. For the VCL, it uses an ownership model with notifications. New RTTI uses an object pool controlled by a context. You can use (refcounted) interfaces instead of plain objects. Some objects are automatically managed already (strings, dynarrays, variants, interfaces, anonymous methods). Third parties have alrady developed smart pointers and/or managed object pools. C++ uses smart pointers and stack based objects with automatic management (default constructors, etc.). Other languages use a real garbage collector. Each of these have their pros and cons. But you certainly don't need refcounting. There are alternatives. FWIW, you could also do what Objective-C on the Mac did: use manual reference counting (MRC) and autorelease pools. But that would have the same problem as your solutions: different kind of objects that are not really compatible, i.e. that do not easily co-exist. Oh, I agree that memory management is not only something that can be done wrong, it is also something that takes time and consideration, something I'd rather leave to the runtime, no matter how. But ARC is not the only way to achieve this.

Yes, you said so. No easy coexistence, then. Separately written containers, so they would have to live in separate worlds. Is that what you really want? FWIW, completely abandoning ARC is also backwards compatible. And that does not expose such problems.

LOL! I mean, coming from you, that is funny. <g>

I don't have the source right here, but IIRC, it is not a function, it is an explicit cast,: class operator Implicit(const Sh: Share<T>): T; class operator Explicit(const O: T): Share<T>; or similar.

No, it isn't. It can make a lot of sense, especially if you want to mix both types. Your way means you can't easily mix DEADÀRCed and ARCed objects. There may be other reasons to query the ARCedness when objects are mixed, and that must be done at runtime. Again, no easy or peaceful coexistence.

Are you against generics too? I have done generic shared pointers, and they did not necesarily require a type in braces, when used. Type inference was actually implemented for generics well before it was implemented for inline variables. But I was right: you obviously have absolutely no clue about mrecords, but you condemn them and make silly claims about them. That can easily be seen in your posts, and that proves I am not wrong. Jeez! FWIW, my shared pointer works like this: var MyObject := Share(TMyObject.Create); No more. I hate introducing keywords when a library function/construct can solve things as well.

Wait a second. I can only pass non-ARCed objects to that container? Well, thanks for making my proof. These types can obviously not peacefully co-exist. You obviously can't pass ARCed objects to that container. Perhaps you could, with a second overload, but then later on, in the destructor, each object (you would have a mix of ARCed and DEADARCed objects) would have to be queried at runtime, if it it must be released or be freed. So no, not at compile time. This means you can use one kind of objects along with the other, but they must live in completely separated environments, or if you mix, you must constantly query their ARCedness at runtime. Well, that is not peaceful or easy coexistence. That is similar to using objects as interfaces and as objects at the same time. Not exactly the same, but very similar. I mentioned that already, i.e. the problems with interfaces. There are a few others too.

Are you saying that I am wrong? Calling you on your behaviour is not rude. You obvioulsy have no clue about mrecords, but condemn them anyway and make absurd claims about them (e.g. about the curly braces). I merely called you on that. And I don't want to convince you not to open source the compiler, because you can't do that anyway. You want to convince others, I don't, because I don't have to. I am merely telling you that your plan won't work and that is not a good idea.

And It would, on compile-time. At compile time? procedure MyContainer.Add(A: TObject); Add does not know if A is ARC-ed or not. But it may have to know, in order to free it, much much later on, or in order to refcount it. Not at compile time. It must query the object at runtime, perhaps even several times.

If you use reintroduce, you hide the virtual implementation. But if you want to overload it, and leave the virtual method visible and accessible/inheritable too, you must use both reintroduce and overload, in the correct order. This is documented somewhere.

No, it hasn't. This is a rhetorical technique invented by Bruce McGee No, it isn't a rhetorical technique, It is true. I have seen it myself. As long as I have been on the newsgroups (1996), people have called Delphi doomed or dying or something along those lines. Mainly because of poor marketing it has been in a much worse state and people were almost right before Borland forked off CodeGear, and yet is still going strong (yes it really is, see below). No, it's not "going strong". That's simply factually inaccurate. According to Embarcadero, and from what I see in forums like this, Idera's and on Stack Overflow, I think it is accuratet. I see lots of newbies coming from other languages having problems with some of the idioms (like 1-based strings <g>, static arrays or pointers). It seems to be selling well, despite some of the current problems with 10.3. Oh, it is not doing as well as your beloved Python, but that's OK, Delphi has never been the top choice, but still strong enough to survive and get better (you don't survive if you don't improve).

Well then, if it is not so great, it should even be easier to do better. But obviously, not even that is done by anyone. So again, what makes you think you could find capable people inclined to spend a lot of time to produce a product you would like? What if they decide in a direction away from your wishes? Another OS project? You said a company could hire capable developers (and note that a run-of-the-milll C++ developer is not nearly a language developer -- these do earn good money, if they are good -- and if they are not good, we don't need them). Well yes, perhaps, I am not so sure they actually would. And if they do, these developers would fix the problems they encounter, not yours or mine.

What makes you think so? I don't see why they should be ugly, limited or inefficient. They would be far more efficient than ARC. ARC routines would have to check if an object is ARCed or not, each time. Code that receives objects must know if it i must free them or not. Etc. Would be a terrible mess and you would be draggin along the refcounts. The refcounting routines might cop out early, but they would have to be called for each access. It ia also a mess for the user. He must constantly invesitage if an object must/can/should be freed or not. They would not coexist peacefully.

What a business model. Jeez! Don't tell me that was a serious suggestion?

But then you get what you pay for... You probably want a capable person, and these don't come so cheap.

What nonsense! MRecords were implemented (although not flawless) and there was no indication of curly braces, except for comments. There was not even a special syntax required. You just had: type MyMRec = record constructor Create; overload; // default constructor destructor Destroy; // destructor constructor Create(const Other: MyMRec); // copy constructor class operator Assign(const Other: MyMRec): MyMRec; // overloaded assignment operator end; And you would use the record like any other record. But these special methods would be called where necessary, i.e. calling our implementation, instead of the runtime typeinfo-based routines like _InitializeRecord, _FinalizeRecord or _CopyRecord. So stop talking nonsense if you don't even know what you are talking about.

I do have my own clinic, and I could call myself CEO, but not, not in the business. And 10 grand is nothing. The "fixer" would have to try to understand the complete source code, would have to find a solution without rewriting the entire compiler and without breaking anything. Think of a few zeroes more left of the decimal point, and not a few weeks, but a few years. And if things go wrong, he would face a lot of criticims and would probably have to fight for his fees too. And what makes you think you can find someone capable of doing or willing to do it at all? Sorry, I have no idea what you want or mean with the above pseudo-code, or with your "ARC = shared pointers backed by compiler magic". Makes no sense. It may dampen your enthusiasm, but you may want to think about that a little longer. I know what I have said. I don't care about your "ARC but not ARC" ("dead ARC"). I do care about better code generation, but not about laming ARC by not properly counting. I personally find it a pity that they are phasing out ARC instead of improving upon it. But you will not see non-ARC code peacefully coexist with ARC. Your kind of "dead ARC" may coexist with proper (live) ARC (although I even doubt that), but what would be the advantage of carrying along that much dea weight? That would not be an improvement. And of course the compiler/runtime can be made thus that they can be useful. They were almost there, but there were some issues. I'm sure these could have been solved, had there been enough time. And the main advantage would not have been shared pointers, it would have been the opportunity to manually tune records with methods and operators to make them much more lightweight and performant. Shared pointers and some other scenarios would have been a nice side effect. You could write your own refcounted types, including optimized dynamic arrays (these also suffer from the runtime typeinfo/RTTI slowdown). You could have dynarrays with COW without havin to use interfaces. etc.etc. But that is off-topic. Again: there is no indication that an open source team, well paid or not, could or would do better. FPC is already well on the way, so why didn't anyone create a new team, fork FPC, concentrate on the few platforms that make sense and make that great language you want? Because no one wants to pay for it, or has so much enthusiasm he will do it for free or is capable enough. If opensourcing had been a viable alternative, someone would have improved FPC, or a fork, well beyond Delphi already (either by a team of highly motivated and capable enthusiasts, or a team of capable paid developers). And if Embarcadero can build a great IDE and debugger, what makes you think an icnlined team of developers couldn't do the same? So there would be a better Lazarus with a proper debugger, and there would be an incredibly cool compiler and runtime. But obviously that didn't happen yet. Guess why.

And you think that unpaid open source volunteers would do a better job because...? Or, if someone were to be hired by a group of Delphi enthusiasts, what makes you think he/she/they would be cheaper or better?

Ah, yes, once again. <sigh> Delphi has been called doomed, or dying, or on the way out for almost as long as it exists. And yet it is still going strong despite the current problems. Yes, it has issues, and I wish this was not one of those darned problematic versions that pop up every now and then, but calling it doomed is hyperbole, IMO. FWIW, Frazer: We're doomed! We're all doomed! Doomed I tellya! Mainwaring: Frazer, stop rolling your eyes like that!

I have absolutely no idea what Marco said. Doesn't change what I wrote. I do think that the efforts to improve and change the compiler have not diminished, although it doesn't always run very smooth (shit happens). Could that be what he meant? FWIW, probably off-topic, but I do also think that the way mrecords were (IMO hastily) implemented was wrong and not fixable in the time period they had. But the removal was also a little too hasty, and many of the code generation changes they deemed necessary (they did; I didn't always) were not completely removed and still affect the current state of affairs. They should, IMO, implement managed records properly, not only so they could create shared pointers and the like (that can be done with the hlp of interfaces already, see Barry Kelly's blof posts and things like Spring4D). No, that is not the reason I want them. Mrecords would give us an opportunity to greatly tune our records by avoiding the slow runtime typeinfo/RTTI based runtime processing and replace it with manual compile-time tuning. But that is off-topic already.