AlekXL

6 hours ago, Markus Kinzler said:

If everyone will do this than delphi will be history immediately

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

58 minutes ago, Darian Miller said:

IMHO, there is no amount of bitching in this forum that is going to change their direction one bit.  

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

23 hours ago, Rudy Velthuis said:

That is off-topic. 

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

2 hours ago, Der schöne Günther said:

Proper debugging capabilities are way more important

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.

1 hour ago, Rudy Velthuis said:

It would make it slow and a terrible mess. No thanks

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.

On 4/23/2019 at 11:47 PM, Rudy Velthuis said:

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. 

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.

On 4/23/2019 at 11:13 PM, Rudy Velthuis said:

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.

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"

On 4/23/2019 at 2:50 PM, Микола Петрівський said:

So authors of this codebases also were perfectly aware of problems related to mixing different memory management models, and have separated them on language borders.

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

19 minutes ago, Uwe Raabe said:

Also f.i. filtering members by kind and visibility with the filter buttons is probably easier and faster than using the context menu

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. 

19 minutes ago, Uwe Raabe said:

There are quite a number of people saying they cannot work without MMX (me included)

Ask them then! We need community wisdom, dont we?

19 minutes ago, Uwe Raabe said:

You cannot please everyone.

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.

6 minutes ago, Daniel said:

Ah grumpy Alek - it's you again ... . I knew I remember that harsh sound from somewhere

Missed me already, did you?

3 minutes ago, Daniel said:

What is so hard about being constructive and positive? 

And where's the fun in this?

55 minutes ago, Uwe Raabe said:

Start typing in the Search field in the Member Search bar. 

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

1 minute ago, Uwe Raabe said:

I guess that is not feasible. I cannot foresee when I will have time to work on MMX and what I am going to target when I have. 

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.

29 minutes ago, Daniel said:

Technically we could include any graphic there, but negative reactions will not be implemented here.

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.

36 minutes ago, Markus Kinzler said:

This isn't the official embt forum! If you dislike Marco closeing a thread in their forum, complain about in there! 

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

Quote

but an ARC-enabled object won’t easily coexist with a non-ARC-enabled one

And this was re-chanted by Rudy and then Dalia too many times, if you didn't noticed.

and did you, Markus confirmed , writing

Quote

Yes, I am the same opinion as member (and moderator).

about ad hominem is unacceptable?

On 4/18/2019 at 5:43 PM, Bill Meyer said:

What is truly unacceptable, in my view -- and I am just a member, not a moderator -- is ad hominems

4 minutes ago, Daniel said:

- but you are not allowing other points of view without insulting other members of this community. Stop this now.

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

2 minutes ago, Rudy Velthuis said:

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

Marco wrote

Quote

Can I ask why? Pascal and Object Pascal variable scope and lifetime and significantly different than the C/C++ counterpart. There must be a terribly good reason for breaking a stable behavior of the language – and I fail to see it here

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

Quote

We ended up doing it in 10.3 Rio...

Do you see any explanation of this?  No. Like out of blue air.. And why votes disappear?

1 hour ago, Dalija Prasnikar said:

that would still suffer from various problems - because no matter how far you go (and even if you can make your model work slightly better that the current one) you still cannot successfully mix ARC and non-ARC objects

Again, baseless non-technical dismissal

1 hour ago, Dalija Prasnikar said:

Not only you didn't solved original problem, you also introduced another one

Which is? Problem was and is lack of more than just manual memory management. And what problem I introduced?

1 hour ago, Dalija Prasnikar said:

your model is completely incompatible with existing code

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

1 hour ago, Dalija Prasnikar said:

For me that is end of story. This is not viable option, no matter how you turn it.

You don't even realize how incoherent this statement is, do you? Wrong, misleading. Harmful even.

37 minutes ago, Rudy Velthuis said:

It is quite a bit to claim you only know the truth and the people at Embarcadero don't

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.

39 minutes ago, Rudy Velthuis said:

You don't have to convince me,

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.

1 minute ago, Rudy Velthuis said:

your bad arguments and because of your behaviour

dismissal again? As you wish.