In an effort to promote general awareness of Delphi I have moved a recent blog post about Delphi to CodeProject and I will post more articles there about Delphi.
In an effort to promote general awareness of Delphi I have moved a recent blog post about Delphi to CodeProject and I will post more articles there about Delphi.
Please consider voting for the article to help up it in the global CodeProject visibility. This article is extremely short, more of a snippet but I have some more detailed articles I plan to post shortly:
https://www.codeproject.com/Articles/1252167/Delphi-Language-Progression-Suggestions
CodeProject gets a LOT of traffic. While they have Delphi listed as a language, there are very few articles there. Please consider joining me in posting Delphi Articles on CodeProject and help raise the awareness of Delphi itself.
https://www.codeproject.com/Articles/1252167/Delphi-Language-Progression-Suggestions
Please consider voting for the article to help up it in the global CodeProject visibility. This article is extremely short, more of a snippet but I have some more detailed articles I plan to post shortly:
https://www.codeproject.com/Articles/1252167/Delphi-Language-Progression-Suggestions
CodeProject gets a LOT of traffic. While they have Delphi listed as a language, there are very few articles there. Please consider joining me in posting Delphi Articles on CodeProject and help raise the awareness of Delphi itself.
https://www.codeproject.com/Articles/1252167/Delphi-Language-Progression-Suggestions
I do agree on variable initialization on declaration, but I'm not that fan of being able to declare variables on the fly. Is not that clean and moves significantly away from Pascals principle of declaring everything in advance (Interface/Implementation) which personally brings some clarity while looking at code, that said, I'll not mind to offer them on limited scopes e.g. loops. In any case I'll probably appreciate more an automatic variable declaration and method synchronization (interface/implementation) like MMX does and a smarter code completion like CodeInsight Plus started to do. Thank you for the article at Code Project, we do need to support your initiative.
ReplyDeleteEsteban Pacheco They are not declared on the fly. Its purely syntactic sugar in most implementations.
ReplyDeleteIt puts the variable declaration nearer the code that uses it, reduces improper variable reuse among blocks, makes copying code easier, reduces line count and much more.
I would bet after trying it you would never want to go back.
A larger more in depth article just posted to CodeProject about Delphi and I have at least one more in the queue.
ReplyDeletehttps://www.codeproject.com/Articles/1252175/Fixing-Delphis-Interface-Limitations
Interesting suggestion. I would already be fine with a simpler syntax for local variables created in the var block.
ReplyDeletevar
y: TStrings:= TStringList.Create;
begin
...
end;
if created in the "var" block then it's freed at the end of the procedure call. Looks for me logical as I have no chance to implement a try/finally block. Syntax sugar for the cases where you do not care that object lives a little bit longer than in a specific try/finally block.
But what if the code looks like
var
y: TStrings:= TStringList.Create;
begin
...
y:= z;
should that be allowed or should the compiler raise an error to protect such local vars.
Günther Schoch User error, dont use an auto for such. That is why I proposed a new keyword to allow control by the dev.
ReplyDeleteI've made several updates to the article.
ReplyDeletehttps://plus.google.com/photos/...
ReplyDeleteHave e look at Remobjects Elements
ReplyDeletethey have done a really good job on extending the language
Friedrich Westermann RO has a lot of cool stuff, but Elements is not Delphi nor does it act as a stand in replacement or extend the existing Delphi language in place.
ReplyDeleteChad Hower You are right, my comment was more to show what can be done with the pascal language, if someone wan't to do it......
ReplyDeleteThe problem with auto and to some degree using, is that people will want to downscale an auto to a non auto in some circumstances. Ie. the value being stored in some other structure occationally.
ReplyDeleteThe reply could be "just simply do not do that", but the request for some feature handling that would come.
Im mentioning "to some degree" about using, because it does act like a scope, and as such could be perceived more of the owner of the value by the general public.
But auto statement would need to be implemented with refcounting imo, and thus some sort of automagic conversion from a regular object to an interfaced refcounted object should be the way to handle that.
Kim Madsen
ReplyDelete1) If you might not want auto, dont declare it as such. Simple.
2) It does not and should not be ref counted. Its a simple implicit finally that calls free for all autos. Its very very simple and without making major changes to anything.
Difficult to know what you are hoping to achieve here. What makes you think that the decision makers in Embarcadero will read your articles. If you want them to heed your suggestions, you need to submit an issue to Quality Portal.
ReplyDeleteDavid Heffernan Its not about reaching the Delphi decision makers. They already read my posts, there is no need for me to highlight it to them.
ReplyDeleteGetting Delphi articles on CodeProject however exposes the fact that Delphi is still alive to many other devs.
That post on interfaces is one of the most confused things I have ever seen.
ReplyDeleteThe post on interfaces is not confused. I can use the word "confused" when referencing Delphi's Interface implementation though. Reference counting shouldn't be part of it, since the beginning.
ReplyDeleteAlexandre Machado How would you have handle COM interface ref counting?
ReplyDeleteWhy a single common ancestor for all interfaces is required? Or... _AddRef and _Release could have been introduced in some other interface, instead of IInterface. This was a (bad) design decision.
ReplyDeleteIn other words:
ReplyDeletetype
IInterface = interface
['{00000000-0000-0000-C000-000000000046}']
function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
end;
ICOMInterface= interface(IInterface)
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
end;
Do you see something technically impossible here?
Alexandre Machado In essence it's a fair point. Certainly it is a shame to force COM IUnknown onto all interfaces.
ReplyDeleteHowever, I still think that you'd want, even for these proposed non-COM interfaces, to have some automatic way to manage the lifetime of the implementing object. In .net there is GC. Delphi has chosen the path of ARC. So if your non-COM interfaces existed then I guess they would just use a different form of reference counting.
Alexandre Machado
ReplyDeleteProbably the same "reason" we have:
TObject
--TInterfacedObject
--TPersistent
----TInterfacedPersistent
----TComponent
instead of:
TObject
--TInterfacedObject
--TPersistent
----TInterfacedPersistent
------TComponent