Delphi compiler need to be opensourced

[Rudy Velthuis 91]

11 minutes ago, AlekXL said:

clarify full signature of Share function.

(signature stands for full declaration)

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.

Edited April 18, 2019 by Rudy Velthuis

[Bill Meyer 337]

6 minutes ago, AlekXL said:

It's wouldn't hurt anyone to add a keyword or two.

It's less about the number -- though number is a consideration -- than about the thoughtful and deliberate decisions made with regard to extending the language. That said, I dare say we all have our pet topics for improvements we may consider very important. One factor in our assessment of the keywords issue is that we have limited awareness of future plans to extend; we cannot properly assess without more data than we presently have.

[AlekXL 8]

7 minutes ago, Rudy Velthuis said:

Your way means you can't easily mix DEADÀRCed and ARCed objects

Correct. You shouldn't usually mix them. Some instance types would live on ARC, some would live like "normal".

To mix them, You need to understand what exactly are you doing. The whole (and any) ARC memory model is conceptually more sophisticated that simple manual memory management. No need to pretend it is simple, I opine.

13 minutes ago, Rudy Velthuis said:

Your way means you can't easily mix DEADÀRCed and ARCed objects

My way is backward compatible, gives opportunities to those who dare use them and wouldn't force anyone any particular code style.

15 minutes ago, Rudy Velthuis said:

There may be other reasons to query the ARCedness when objects are mixed, and that must be done at runtime.

But if yes, they are rare, overhead is low, who cares?

[David Heffernan 2345]

I'm just curious. Do either of you have a stopping condition? 

 

[Rudy Velthuis 91]

2 minutes ago, David Heffernan said:

I'm just curious. Do either of you have a stopping condition? 

 

LOL!

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

[Rudy Velthuis 91]

30 minutes ago, AlekXL said:

Again, you are rushing, the container you quoted is designed for ARC

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.

[AlekXL 8]

2 minutes ago, David Heffernan said:

I'm just curious. Do either of you have a stopping condition? 

And why should you care? Don't like it? Don't read it! With all my due respect.

8 minutes ago, Bill Meyer said:

I dare say we all have our pet topics for improvements we may consider very important.

I worked out the whole on-demand ARC syntax, semantics, and philosophy upon @Joseph MItzen  (valid) complain about Delphi current memory management state.  And invalid lame excuse of Marco Cantu to lazy about doing ARC right

I did it from scratch.  And I opine this is best way to do ARC on Delphi right. ARC is of utmost importance, too. Non just your lambda or automatic properties syntax sugar.

[AlekXL 8]

3 minutes ago, Rudy Velthuis said:

Yes, you said so. No easy coexistence, then. Separately written containers, so they would have to live in separate worlds. 

No. Containers are shared. TList generic could easy hold both ARCed and non-ARCed instances.

Yes, such container would  specialized differently by compiler, but who cares?

As well as TDictionary, TQueue, or TStack, etc.

But yes, normally one should not mix them. However if you are expert, and know exactly what are you doing, then yes, go ahead and mix them.

Couple of unsafe operators -- thats easy.  Just don't complain, if you miscalculated and such mixture backfires.

[fredvs 0]

On 4/14/2019 at 12:45 AM, AlekXL said:

>if you wish check this project https://github.com/fredvs/mselang

> compiler very well written, clean, fast code, based on LLVMç

> still lack a framework as vcl or fmx 

 

Yet another reinventing the wheel? We already have Oxygene for that. I hate fragmentation (burn the heretics!).. We already have our resources stretched thin.

And under viral license, so you can't even borrow code from it, without being infected. With FPC we have our plate full. So that guy can shove it..

Hello.

 

Could you develop a little more?

Sorry but I do not see comparison with Oxygene and MSElang.

And what are you talking about viral license, MSElang is LGPL.

 

Edited April 18, 2019 by fredvs

[AlekXL 8]

 

1 minute ago, fredvs said:

Sorry but I do not see comparison with Oxygene and MSElang.

They are both Delphi incompatible, I believe. Fakes. Lure a decent Delphi coder into a schism. Provoke  writing code any other Delphi developer can't use. Taking away solidarity and unity of Pascal Community. Fragmenting already small community. Causing efforts to promote Pascal even harder. Burn the heretics!

9 minutes ago, fredvs said:

And what are you talking about viral license, MSElang is LGPL.

LGPL is half-bad when you use code in dynamic library, without any considerable modification. But what happens, when you borrow code to your proprietary application?  Violation! Or extend the LGPL code? MSELang is not a library I presume, so it is unclear what happens. You can be sued -- that's for sure, whether you win or loose in the court of justice  -- you'd loose at least time, and money for lawyers.

You can borrow LLVM code, as well as BSD, MIT, Apache licensed sources. Just give the devil his due -- some credits, and you're safe. And GPL/LGPL is infection. Any linking with it is a legal threat.

[fredvs 0]

Quote

Burn the heretics!

Ha, ok, so sorry for the noise.

[Jacek Laskowski 57]

10 minutes ago, AlekXL said:

Burn the heretics!

fredvs is MSElang developer, I think so.

[Daniel 417]

41 minutes ago, AlekXL said:

And why should you care? Don't like it? Don't read it!

It is pretty obvious that you do not care. You should care because this is a public forum, not just yours. 

Now we have told you several times to move your specific discussions about technical details of the Delphi-language to a separate thread. Most of these posts are offtopic now. You did not care at all.

Do I really have to explain to you why it is important for us to stay on a topic? It is not that complicated. If any other person wants find find some information later, they will look for the thread-title to decide for reading a topic or not. This „let us talk about everything“-threads do not help anyone.