Jump to content

Rudy Velthuis

Members
  • Content Count

    174
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Rudy Velthuis

  1. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  2. Rudy Velthuis

    Delphi compiler need to be opensourced

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

    Delphi compiler need to be opensourced

    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.
  4. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  5. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  6. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  7. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  8. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  9. Rudy Velthuis

    Class inheritance and hides method

    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.
  10. Rudy Velthuis

    Delphi compiler need to be opensourced

    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).
  11. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  12. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  13. Rudy Velthuis

    Delphi compiler need to be opensourced

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

    Delphi compiler need to be opensourced

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

    Delphi compiler need to be opensourced

    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.
  16. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  17. Rudy Velthuis

    Delphi compiler need to be opensourced

    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?
  18. Rudy Velthuis

    Delphi compiler need to be opensourced

    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!
  19. Rudy Velthuis

    Delphi compiler need to be opensourced

    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.
  20. Rudy Velthuis

    Delphi compiler need to be opensourced

    If it were so desirable and/or so easy to maintain the Delphi compiler, I wonder why FPC didn't make Delphi obsolete already. I guess because after all there are not so many people capable of maintaining, nor enough people inclined to do it. I also gues that the task is not so easy. I have said it before, and I'll say it again: I use a lot of open source and I love open source and I have participated in open source, but the notion of "open source it so you can always fix it yourself" is pure nonsense. Even if I suffer from some bugs (and indeed, Rio seems to have quite some new bugs and slowdowns caused by the -- incompletely -- removed mrecords, i.e. the runtime changes still affect current code, even if mrecords themselves were removed again), I am not capable nor willing to read the entire (possibly hard-to-read) source code of the entire compiler and then I'm not capable of making a decision what I can safely change without causing a multitude of other bugs. I will leave that to others. I am not so sure there are enough "others" who could or are willing to maintain the Delphi compiler. Nor am I willing to hire someone to fix them for me. People who could do that would probably require large fees too. So no, open sourcing the compiler is useless, IMO. Rather lean on Embarcadero and confront them with "love withdrawal" or other sticks behind your back and let them do it. I agree we need bug fixes and new features. But open sourcing won't provide them. Only pressue on Embarcadero can.
  21. Rudy Velthuis

    Delphi compiler need to be opensourced

    They are not **objects** that can actively reference **other** objects. See how this doesn't even work for interfaces. What makes you think it would be different for objects? Again: no, they can not easily live together What bar? Are you talking about a passive string again?
  22. Rudy Velthuis

    Class inheritance and hides method

    I didn't know that, but it looks like it has the equivalent but opposite meaning of reintroduce in Delphi. Of course it is useful, in C++ too.
  23. So do loops in other languages. And even a simple language like C has while, do while and for loops. I don't see that as overkill. You use what best suits you. After all, carpenters often have different kinds of hammers (and different kinds of planers) too. <g>
  24. Rudy Velthuis

    Delphi compiler need to be opensourced

    Heh, that doesn't even work properly for interfaces, even if they are not refcounted, You can make objects not being refcounted, but they would still live in an ARC environment, with al the possible problems and disadvantages. Note that your example contained a string constant, not just a non-refcounted object. Obviously you thought about it, but didn't think this through to the bitter end. So again: no they will not coexist easily.
  25. Rudy Velthuis

    Delphi compiler need to be opensourced

    You are really an expert in convincing others to support your ideas. Using a tone like that is certain to win them over. <g> I did not read the entire topic (7 pages an counting...) and I will not. If you had anything useful to say, then repeat it. But no matter what you wrote, I'll write it again: no, they won't easily coexist at all.
×