AlekXL

You should never underestimate people's foolishness, Markus. Smart people are always a minority.

perhaps, our time or money investment to FPC/Lazarus could change EMBT behavior. Skip subscription fee once, and invest it to the better cause. Let EMBT know, that you did so..

I would politely disagree.

actually, the only way to fix it is to have compiler opensourced and local skilled software engineer hired -- to investigate such issue. He could resolve issue, and then report it! So vote the issue

That's it! It's the debugger that makes all the difference. Merlin pants, I'm working on Lazarus project right now, and multi-threaded to boot. Do you know that there is no way to switch thread while debugging? No even in trunk Lazarus? Neither on Win, nor Linux? This is show stopper! -- @Nasreddine Lazarus may look ugly, but it's the only real way to improve things for pascal now. We need to concentrate our efforts on Lazarus. Additionally you can actually write IDE-agnosttic pascal language server -- debugger, code-insight, etc -- and sell it, after creating bindings for Lazarus, VS-code, IDEA, etc..

I am wondering, in that possible to use FullDebugMode features of FMM4, in Lazarus/FPC? At least on Windows?

And are you asking to help for free, or you paying? If the latter, then well, I could give you some..

@Nasreddine It's not that's difficult to create decent editor. Intellisense/Code Insight -- that's more tricky, but still doable. There are lots of examples of this. Creating yet another source editor is boring, low hanging fruit But here the catch, the real, cruel truth: it's the debugger - the thing that makes all the difference.. Do you know many debuggers? Decent ones? Especially for languages which compile to real executable? Even Delphi IDE native debuggers are horrible on non-windows platforms. If you really want to contribute, you should probably give your effort to tweak existing debugger engines, like LLDB, GDB, Titan for usage with generated-from-Pascal executable -- and especially on android.

Discussion started with: This is valid point, I must concede. We need to have an option to reference count just for explicitly designated object types and variables. And a first-class one, without need to build an interface wrapper. Which means not some crappy wrappers like shared_ptr, no, lets introduce compiler magic and (non-breaking) language changes. like FObject: auto TObject; // compiler, just manage the lifetime automacally type TMyRefObject = class auto (TObject) // all instances are automatic var manualRef := unsafe(RefCountedObject); // Compiler, I understand the risk, just give me raw pointer var autoInline := auto TObject.Create;// compiler, manage it automatically

Mess how? Don't like it? Don't use it! Terrible mess is what's going to happen with mobile arc-enabled code, when current ARC disappears. People who invested their time in mobile development is being dumped. We got PR article instead of solution. Marco announced, that EMBT decided to break nextgen code-base. Instead to addressing the problem, he just did PR-thing, damage control, giving excuses about why this was necessary. And what about Desktop? Other languages are blooming with innovations, and Delphi is stagnating, we still forced to use only one memory model for object instances! ARC is great thing, especially when it's non-compulsory. I believe, there are 3 memory management models, and each of them has 2 cool features out 3: simplicity, productivity, and performance Classic model offers simplicity and performance. Productivity -- not so much -- more code to write, more mistakes to make. GC sports both simplicity and productivity. But not performance. ARC offers productivity and performance. But lets not be fooled, ARC is not simple. Why Delphi can't have two of them? Even now there is a way to make some tricks about mixing non-ARC and ARC instances. This code actually supported by classic compiler [result:unsafe] function Fast():IInterface; begin result :=TInterfacedObject.Create(); end; procedure DoIt(); var [unsafe] intf:IInterface; begin intf:= Fast(); end; I don't want GC in Delphi, actually -- I'd go to C# for that. But ARC is nice. And I'd prefer to not being forced to extract interface for each and every object I want ARCed. And, by closing the feature request with "Won't FIX" resolution he thought , it would never be a time, nor reason, right? Otherwise, he'd say: OK, let this stay open, and maybe we need it at some time.

Then why he closed the issue with "Won't Fix" resolution? Some issue don't get fixed or implemented, but Marco says: "We should consider all options", and keep them opened didn't he? But in this specific issue his resolution was "Won't Fix"

there are a lot things, in which C++ sucks: 1. lack of try ..finally 2. lack of properties sematics 3. lack of proper RTTI and attributes 4. lack of proper unified exception model for both software and hardware exceptions But actually due to outstanding support of operator overloading, C++ allows ARC-enabled objects to exist and even to mix them with simple memory mode Delphi wouldn't have such luxury -- because shared_ptr magic is, if I am not wrong, based on -> operator overloaded. Well, Delphi doesn't have it, just as it doesn't have smart enough compiler. Delphi implementation of shared_ptr patter would be ugly, and ineffective -- mark my words. Neither it will help to address broken compatibility for nextgen code. My approach would. Truth is -- return to classic memory is right step, but it is step backwards, nonetheless Mixed On-Demand ARC approach would give Delphi an edge, unlike poorly implemented non-extendable mrecords. The said model would allow user to choose, whether and when to use ARC, and use those models side-by-side easily Even mixing those object would not be difficult: not simple, but still relatively easy. Because ease is about productivity, and simplicity about understanding

Faster how? You win maybe 1-2 seconds, on rarely needed task, but bloat the toolbar for good. Add one I tool-button to show specific dedicated popup to filter based on visibilty. Another one, with specific dedicated popup for entity filter : All, types, routines, g_variables, storage members Place entity search edit box, to right. Done. By default there should be no other controls on Structure view toolbar. And don't forget to de-bloat the popup on entities. Popup menus are also called Context menus -- this is all about context, if some action is not applicable to the entity selected, Popup menu should not show it. Ask them then! We need community wisdom, dont we? You can try. I opine that MMX windows should be separated to two or more dockable windows. If one need those allegedly useful other features, let him dock those windows together.

Missed me already, did you? And where's the fun in this?

And it just don't work. Guess I am doing this all wrong.. But it doesn't matter, this tool is not that important or powerful to spend my time learning it. I want it work with zero-assumption. Look at Gexperts procedure list, or CnWizards couterpart -- they just work. Only problem they show routines only. 1. Look at the picture. Window 1 and 2 should be merged. Bloat-ware -- anything aside syntax entities -- removed! 2. Text edit number 3 -- don't know what it does, it doesnt even show a tooptip about -- and don't care. Send him to Mordred, too. There is no place for multi line editor in docked, space-limited environment 3. "Member search bar" should be "Entity search bar" -- filtering out both types and members, containing the typeword 4. Window 5 /toolbar just wouldn't die, would it? I right-click, choose Hide, and guess what? Send it to already known address. 5. Get rid if smart-ass chevron logic --completely -- they are confusing and counter-intuitive. 5. Look at the IDE native structure window -- I want MMX to take no more space, than this

Understood. Well, I'd love to see more reasonable interface though. Not new icons, mind you. But rather MMX-implemented Structure View -- it lacks "Incremental Filter", and therefore barely usable. I opine :simply by adding such (dockable) window , would make all the difference. Currently MMX Windows is bloated, counter-intuitive and too complex to grasp.. Icons too -- I have no time memorize their meaning. I'd rather use simple popup menu with "check-items"

Is there roadmap for the product?

Back to technical: There is also 1 case should be addressed: What if some legacy container class, which only understands only classic instances, would try to create ref-counted one, through virtual constructor? And then attempt to Free it? This should be forbidden, so we need to clarify class reference syntax and semantics TClass= class of TObject;// only reference non-arc instances, backward compatible TClassAuto = class auto of TObject;// only reference arc instances, new TClassAny = class raw of TObject; // reference both, Chuck Norris mode! This way legacy code manipulator would be unable to create/instantiate ref-counted objects.

Too bad..

Yes, also a question about negative reactions? Are they possible? I'd like to know just how many's pet corn I've trodden.. For educational purposes.

Why should complain about fixed issue? Rudy asked, whether is this true, that Marco was against inline variable, and I added a proof. That's it. This is on-topic , about Marco authority -- positive ad hominem reversal -- since he claimed And this was re-chanted by Rudy and then Dalia too many times, if you didn't noticed. and did you, Markus confirmed , writing about ad hominem is unacceptable?

Ok, maybe I overreacted, I corrected post to Dalia. Now it's seems to be Okay.

Marco wrote https://quality.embarcadero.com/browse/RSP-15862 Marco closed this issue, and it remained closed for a long time, until suddenly was reopened, and fixed Marco added them Do you see any explanation of this? No. Like out of blue air.. And why votes disappear?

Again, baseless non-technical dismissal Which is? Problem was and is lack of more than just manual memory management. And what problem I introduced? Well, that's a direct lie. Are you referring old legacy code, my model is exactly to address backward compatibility. Old non-ARC code would not even notice the changes introduced by my model. It would be unaffected Even new, ARC-enabled code would benefit from it - either you instruct your class type to be ARCed, OR in case of library classes, you may force ARC throw variable/field declaration. I can only imagine what a horrible mess it would be, when current ARC disappear, and the code depended on it would cause leaks. My approach will fix that, causing minimum pain -- just fix declaration, adding one directive, auto. And every other approach would cause serious rework You don't even realize how incoherent this statement is, do you? Wrong, misleading. Harmful even.

No only me, obviously. But people in EMBT ? I 'm aware only of Marco. And yes, I believe I know better than Marco. Marco was against inline variables. Somebody strong-armed their introduction to the language. convince you? Please ! That never was a goal. I used you as opponent, to check my design, and to influence others. Somebody who could have similar concerns but no time or inclination to oppose me directly. And yes you were useful. Thanks.