On-demand ARC feature discussed

[Daniel 417]

Alek, I really don’t understand your intentions.

You obviously have your opinion and that’s okay - but you are not allowing other points of view without insulting other members of this community. Stop this now. As long as you act this way, we cannot discuss with each other (read: with you).

 

Rudy - sometimes a discussion must stop when we realize that it will lead to nowhere. Especially in a web-forum with a linear discussion-thread. The tree-based layout of a usenet-group allowed yo to discuss side-aspects for ever. But here this style just captures a whole thread.

[AlekXL 8]

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?

[AlekXL 8]

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.

[Markus Kinzler 174]

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

We are only responsibe for closeing threads here. And we sometimes do this for good reason!

[AlekXL 8]

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

Edited April 20, 2019 by AlekXL
this forum engine is buggy!

[AlekXL 8]

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.

[Dalija Prasnikar 1396]

8 hours ago, AlekXL said:

Which is? Problem was and is lack of more than just manual memory management. 

You may want to rethink this statement since Delphi had more than just manual memory management since Delphi 4.

[Dalija Prasnikar 1396]

5 hours ago, AlekXL said:

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.

Thank you for offering technical proof (in your own model) of what I have been talking about all along. ARC and non ARC objects can exist side by side, but they don't mix well. And that fact brings all kind of trouble like I mentioned earlier - you have ARC based objects when you don't want them to be automatically managed, you have non ARC objects when you would like to have their memory managed automatically, you have TComponent ownership model on top of all that. 

 

You have to deeply know with which kind of objects you are dealing with. That is not simple. Languages with fully automatic memory management models may have their weaknesses with which you may have to deal from time to time, but generally you can just write code without micromanaging objects memory.

 

Anyway, I rest my case... otherwise I would just end up repeating myself. 

[Dalija Prasnikar 1396]

8 hours ago, AlekXL said:

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

Decisions like that are rarely made by single person. Marco is there as company representative, so he speaks for the company and his personal views may be different ones. Also circumstances change, people change, decisions change. There is nothing unusual about that.

 

You can hardly go forward if you keep focusing on the past.

[Rudy Velthuis 91]

On 4/20/2019 at 11:29 PM, Dalija Prasnikar said:

Decisions like that are rarely made by single person.

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.

[Rudy Velthuis 91]

On 4/20/2019 at 3:20 PM, AlekXL said:

(About the decision to implement inline variables after all): Do you see any explanation of this?  No. Like out of blue air.. And why votes disappear?

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.

[Микола Петрівський 10]

On 4/21/2019 at 12:24 AM, Dalija Prasnikar said:

Languages with fully automatic memory management models may have their weaknesses with which you may have to deal from time to time, but generally you can just write code without micromanaging objects memory.

Interesting observation: Android ART is written in C++ and core of Unity (game engine) is also written in C++. In both cases code with manual memory management is doing all hard work, and garbage collected code (Java and C#) sits on top of it. 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. Delphi has to be good in both low level stuff and business logic, so it had to switch to simpler memory management model.

Edited April 23, 2019 by Микола Петрівський

[David Heffernan 2345]

5 hours ago, Микола Петрівський said:

Interesting observation: Android ART is written in C++ and core of Unity (game engine) is also written in C++. In both cases code with manual memory management is doing all hard work, and garbage collected code (Java and C#) sits on top of it. 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. Delphi has to be good in both low level stuff and business logic, so it had to switch to simpler memory management model.

Well, typical C++ code has automatic memory management too using the RAII principle. So that argument falls down I think. 

[Rudy Velthuis 91]

On 4/20/2019 at 3:34 PM, AlekXL said:

that Marco was against inline variable

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

Quote

There must be a terribly good reason for breaking a stable behavior of the language – and I fail to see it here.

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.

Edited April 23, 2019 by Rudy Velthuis

[Rudy Velthuis 91]

2 hours ago, David Heffernan said:

Well, typical C++ code has automatic memory management too using the RAII principle. So that argument falls down I think. 

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.

Edited April 23, 2019 by Rudy Velthuis

[Rudy Velthuis 91]

On 4/20/2019 at 3:25 PM, Markus Kinzler said:

If you dislike Marco closeing a thread in their forum

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.

[David Heffernan 2345]

15 hours ago, Rudy Velthuis said:

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.

I'm not sure what the purpose of this post is but it is pretty off topic. 

[Rudy Velthuis 91]

7 hours ago, David Heffernan said:

I'm not sure what the purpose of this post is but it is pretty off topic. 

What Marco Cantù already said in one of the early threads on these forums: it was about what is probably the replacement for ARC, i.e. a way to (more or less automatically) manage the lifetime of objects that is not ARC. Even inline declared variables are part of that strategy. The replacement is most definitinely not the mixed ARCs discussed in this thread.

Edited April 24, 2019 by Rudy Velthuis

[AlekXL 8]

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

 

 

Edited April 25, 2019 by AlekXL

[AlekXL 8]

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"

Edited April 25, 2019 by AlekXL

[Rudy Velthuis 91]

3 hours ago, AlekXL said:

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"

I explained it already. You really can't get enough, can you?

[Rudy Velthuis 91]

3 hours ago, AlekXL said:

Mixed On-Demand ARC approach would give Delphi an edge

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

Edited April 25, 2019 by Rudy Velthuis

[AlekXL 8]

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.

[Rudy Velthuis 91]

8 hours ago, AlekXL said:

Mess how? Don't like it? Don't use it!

Everything has been said about it. Having two incompatible object models that can't be mixed is a mess.

Edited April 26, 2019 by Rudy Velthuis

[Markus Kinzler 174]

@AlekXL@Rudy Velthuis

 

Please Stop!!

 

We told you to do this already several times now! Our patience isn't unlimited!