Hi

For the ternary operator, why not, but we already have an ifthen() fonction with some interfaces. I think it's simpler to use it than add a new operator (even if we use it in C&co languages).



ARC is out and I think it's a good thing. So, for auto free some objects the "use XXX do" syntax can be a solution, better than a new keyword in the declaration (because we can declare every where now).

The try ... finally ... end syntax don't with FreeAndNil() or Free() in the finally don't bored me. So they must perhaps do a lot of things before working on it, but a new functionality report on JIRA could be an idea.



Love Delphi and have used it since go knows when (i.e. prior to v1).



If there is one feature I have seen in other languages that I would desperately want in Delphi, it would have to be the ability to assign more than one event handler to a specific event - although not being a compiler guru I have no idea how difficult that might be,







An event proxy might be an easy way to preserve backwards compat, and the designer aside you could implement that today with very minimal code needed.



Create a function which you assign to the event. Its an instance on a list of other functions, and it simply calls them all.

Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"



Hey Chad, good to see your sig. I would maybe argue about the priorities, but I essentially agree with all of your suggestions.



Here are a few additional ones that are favorites of mine, some easier to implement than others:



1. async/await. Enough said. Even JavaScript has it now.

2. Abolish the limitations on class helpers (a.k.a. extension methods). Single class helper? Seriously? Why?

3. Strings as case-statement selectors; and if strings, then why not other non-ordinals?

4. Lambdas, as in x => x > 2.



I have more but that's just the top of my list.







Helper limitations, definitely eliminate.



Cases and strings would be great too.



I would LOVE lambdas but they are big. I was trying to focus on things that can be done very easily by EMBT that have big returns and are also a very low QA risk.

Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"



Block level variables:



While I am not against the addition of block level variables, I would assume it would be of more use to people who come from languages that allow this type of coding. I much prefer to declare the variables in a separate section away from the code. It gives me one spot to look for them instead of needing to scan through the procedure trying to figure out where I saw it. This is one feature that I could see causing problems. The same variable name could be used for more then one type making the code harder to read. I would not make use of this feature.



Type inference:



The example you gave seems confusing... the compiler should infer that x is an integer type... but which? obviously xlist is a TStringList because that is defined in the create. When you get into the code "for var x in xList do begin" it would appear that the x should be a string as that is the only type you should find in the string list... unless you are then saying that the x was previously inferred to be an integer... and that the following inference would be that it should know to only fill x in with the index numbers of the existing strings in the string list...



Using statement:



I am with you on this one, it cleans up the code nicely



Auto Free



I am already doing auto free with ARC in Delphi. It does require a little more work in the background but it is well worth it. It works the same no matter where it is compiled to.

procedure MyProcedure; var MyObj : IMyObj; begin MyObj := NewMyObj; MyObj.DoYourStuff; end ;

This has advantages over your method and it is more work. There are times when having the auto keyword would be the better approach, and it would be easy to make it cross platform compatible because it would simply be ignored when not compiling to Windows.

Brian Thomson







Type inference and block level variable declarations are available in nearly every other modern language. They have been well tested and there are no issues with them. Delphi is simply falling behind the curve again in these areas. Its like going back 10 years and fighting against generics.

Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"







Besides that the ARC I am talking about has been a part of Delphi since Delphi 2007. Most developers simply did not make use of it. The compiler handles the reference counting.



When you declare your new class you make it inherit from TInterfacedObject, declare an interface for it (don't forget the [Ctrl][Shift][G] to have Delphi create a GUID for it), and make a function to return a new instance. That's it. The code I showed on the last comment then works as it is shown.









If/when ARC makes it to Windows, then yes the auto is not needed. But who knows when ARC will make it to Windows?

Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"





Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"



Get down prices and waste more money in marketing. Mobile development in Delphi is A W E S O M E!!!! For far the best I've tested (Android Studio, Xamarin, and some others). And there it is. Almost nobody knows it. If they would communicate in a more efficient way, I'm sure the vast majority of apps developers would migrate to Delphi. It's incredibly easy and fast to develop. The only problem I see is: it's so easy that many idiots could flood (more than now) the android market





Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"



Chad, while I think you suggestions are well thought out, I agree with others that they discourage Pascal from being used as pascal.



If you have a LOOP and need a few block variables, then declare a LOCAL Procedure and do it properly.

I think it makes the code easier to read. The mainline of even a routine should be clean.



I was HOPING to see:

Try Except Finally; as a single block (I hate having try try)

Tags: TStringList added at the TComponent level... For much easier state/data management controlling the GUI stuff (Security, etc). Heck, I could even store JSON in there if that made sense.



Anyways, hoping more than 10 people read your article...









I had this article elsewhere and in just a few days it had thousands of hits. I've moved it and another to CodeProject to help raise Delphi awareness.



In about the first 24 hours, this article on CodeProject:

Views: 2,040

Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"







Kirk 10389821 wrote: (I hate having try try)

Lines area a valueable resource to make compact and readable code, we shouldn't waste them.



I am against variables that are declared inside the program code, even if it is only for a loop. Pascal is: Variables are declared in the head of the program and freed after. This is why Pascal is so readable. If you allow declarations inside the program code developers will do it and that is awful (like "exit, continue, ...").



I hate that Delphi goes so pointer orientated like C and not Pascal. The code word "var" for passing variables by reference has nearly be forgotten. I don't like when the compiler does anything automatically. Often it does it wrong or you aren't sure if it does it right. ARC makes me vomit.



In this sense what is called "automatic variables" are a very good idea, that I wanted to propose also. Objects should be created before the program code and freed after the program code. But "auto" is a bad word. It makes the impression that the compiler does anything automatically and that would be a bad thing. The inverse is the case. If you declare it before the program code you have the full control. The declaration should indicate the creator with all parameters and the destructor with all parameters. Creation of objects inside the program code should be punished. There should be a possibilty to pass a parameter to the declaration indicating how many objects you want to create if there is a flexible array of objects.



My own idea would be mechanisms for "expand" and "collapse" for subobjects.



To me, the most interesting use of local variables and type inference would be in for loops, this could actually be the only thing implemented.

for Index := 0 to 10 do begin end ;

As to "auto" variables, the syntax would be more Delphi like if it was post fixed like many other elements:

var MyObject: TSomeClass; finalize;

this would be more similar to the other keywords: default , deprecated , message , register , cdecl , virtual , override ...



But I also agree that it makes for even worse code from lazy developers...







Finalize as a modifier is a cool idea as well.



Loops etc are a common sore spot, but not the only one.

Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"





Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"





As to the ternary operator, I very much prefer a Scala like syntax:

var MyVar: Integer ; begin MyVar := if Condition then 45 else SomeFunction( ' abc' ); end ;

I know that in Scala this is not really a ternary operator but rather the result of an automatic anonymous function, but syntax wise, it looks much more like Delphi.





Chad Z. Hower, a.k.a. Kudzu

"Programming is an art form that fights back"



<pre>I don't agree with these requests because they are reminiscent of a lazy developper who don't want to pay attention to his way of coding:



- Variables at block level = I declare a variable without paying attention to what I have already created;

→ Not clear stack memory consumption for the method → Risk of stack overflow on a recursive code.



- Inference of simple type = I don't know the type of data that I am creating;

= I don't pay attention to the variables I am using;

→ Risk of using an uninitialized variable like in PHP → Random operation of the code.



- Auto variables = I'm not careful to release the memory I used;

→ Risk of not paying more attention to free global variables' memory → Memory leak;



These proposals are really handy for a good developer who makes clean code. But it's very bad to learn how to become a good developer.

For me, only demanding language like ADA allows to learn to code well.</pre>

