Random Thoughts on the Passing Scene #86
26 Sep
- And some people were saying that anonymous methods weren’t useful.
- Joe Stagner of Microsoft really likes Delphi for PHP. He says "[Delphi for PHP] 2.0 is the REAL DEAL and I LOVE IT !"
- Want to help spread the word about Delphi and C++Builder 2009? Here are some cool graphics and banner ads you can use if you want to.
I read Joe Stagner’s Delphi for PHP and noticed the following quote: "They have new 2009 versions of Delphi for .NET and Delphi for Windows as well."
What is the ETA for Delphi .NET roadmap?
Thanks,
September 26th, 2008 at 7:27 pmRick.
Xepol: I prefer stable and error free code than "saving some typing". What happens if you make a mistake and write S := ‘foo’ somewhere after S := TStringList.Create? Actually it throws a compiler error.
September 27th, 2008 at 5:19 amPascal has its rules - for good reasons, and I will be very careful about making it too much alike other languages born to implement different kind of applications, just to "save typing".
Why the "var S" at all ? Most local variable types can be derived from the context.
The type of S is given from the class.create. A for-loop index variable type can be derived from the for-loop enumerable constraints. Booleans can be derived from the expression context.
If anything declarative is needed, I would have preferred this:
begin
var S := TStringList.Create;
…
Actually, I would prefer some sort of scope delimiting of the local variable and definitive rules forbidding re-typing outside subclass scope (ie you can’t first use a var S (as integer) then later a var S (as string) in the same block.
September 27th, 2008 at 7:51 am@Lars
In fact I generally write this code:
var S: TStrings;
begin
S := TStringList.Create;
…
I’m declaring S as TStrings, but creating it as a TStringList, a TStrings descendant. That’s what OOP is about, isn’t it? Or I could do something like that:
var Obj: TMyPesistentClass;
begin
Obj := TMyPersistentClass(GetClass(’MyClassName’)).Create;
…
That construction: var S := TStringList.Create;
will not handle such cases in the same way.
Regards
September 28th, 2008 at 7:45 am@Xepol:
The code using TStrings/TStringList was just an example that there are times that the compiler doesn’t know the actual class that I will use. So… The "var s:= TSomeClass.Create" construct is not able to handle all situations.
If less typing is your main concern, there is a refactoring "SHITF+CTRL+V" that will declare S as TStringList for you, and save you a lot of typing
CodeGear should focus on bring new value to their customers, evolving VCL, database access layers, etc. rather than creating cosmetic changes to the language itself, IMO.
Best Regards
September 28th, 2008 at 2:18 pm@Xepol
"The compiler isn’t stupid after all"
Indeed not, but programmers often make stupid mistakes.
ime - the clearer you have to be in your code the more likely you are to catch *yourself* making a dumb mistake.
September 28th, 2008 at 2:19 pmhow about this form for overriding the declaration type of S?
begin
var S := TMyStringList.Create as TStringList;
…
end;
S is not available past the end of the block?
September 28th, 2008 at 10:51 pmWe seem to be talking about type inference here and a lot of posters seem to be scared of it.
For what it’s worth I’d love type inference just like MS recently introduced to C#. In other words you could be able to write:
begin
var S := TMyStringList.Create;
for var i := 0 to S.Count-1 do
…
end;
Personally I’d be happy to see the majority of Delphi development going to language/compiler enhancements. I’m happy with D6 IDE and database doesn’t mean much to me. My product is a numerical FE package with a powerful GUI so Delphi is perfect.
Obviously I realise that other Delphi users have different needs to I totally accept that there will be a lot of developments that target users other than me. Just so long as language/compiler developments don’t get forgotten and in recent times there has been good progress there: operator overloading, generics, closures etc.
Now the real icing on the cake would be the cross-compiling 64 bit compiler. I guarantee I would buy that!
September 29th, 2008 at 1:30 amCompiler/language improvements should be driven by other reasons than "less typing".
September 29th, 2008 at 5:48 amType inference was introduced in C# 3.0 to support features borrowed from functional programming (especially to support LINQ, I guess, anonymous types looks to be introduced for the same need).
Type inference can’t simple use the first declaration and use it, or it would be a great stopper of inheritance - IIRC there are algorithms to choose the most general type to be used, yet introducing new code the type can change.
IMHO, C# is chasing more dynamic languages like Ruby, because they cover the same market - web applications - most of C# development is targeted to.
Adding new features to Delphi should be a different approach to the "me too" one. Would such a feature improve applications, beyoond "less typing"?
"me too" and "less typing" are not language features worth pursuing. If I want C# features I will use C#! (OMG! I can’t believe I typed that!).
Besides those kind of features tend to bastardize the language.
I agree with some of you that are set on better IDE, 64 bit support, cross compiler, etc… Deliver that along with bleeding edge innovation and I will go out of my way to use Delphi (not that I don’t do that today :P)
September 29th, 2008 at 4:49 pmI am not to bothered by less typing as I find the more typing the easer the code is to read in eight years time. But a good way to save typing is to have an intelligent editor. if we had a programmable editor a la Brief a lot of the declaration and instantiation could be done by the editor.
October 1st, 2008 at 12:49 pmBob –
Have you taken a look at what you can do with Live Templates?
Nick
October 1st, 2008 at 12:55 pm