Baby + Bath Water
Case insensitivity is A Good Thing.
Case sensitivity is insanity when it comes to programming languages, and suggesting it exposed a contradiction in your own pecadiloes....
On the one hand you dismiss the separate interface/implementation sections as flawed and point to the need for IDE support to make it workable as evidence of those flaws, and then invoke the wonder of IDE support to make case sensitivity more workable.
Just because everyone else in the room is smoking does not make it A Good Idea to take up smoking.
You also reveal a slight lack of familiarity with Delphi as IDE tools for not only navigating but CREATING missing interface/implementation declarations have existed for many, many versions already.
Ctrl+Shift+Up/Down will navigate between interface/implementation
Ctrl+Shift+C will complete the declaration of the type under the cursor
And without separate interface/implementation, further IDE support is needed to make code browsing and navigation an acceptably efficient - and dare I say pleasant - task. The lack of separation between declaration and implementation in C#/C++/Java is the principle reason that code created in those languages becomes intensely difficult and cumbersome to navigate.
Sure it makes it "easier" to CREATE code but code spends a far greater time merely existing and having to be maintained than it does being created.
Similarly the lack of clearly defined declarative areas for variables and the like.
You stumble across some code using some variable - it's type may not be immediately apparent to you (sidebar: type inferencing is great for compilers who have the gift of perfect knowledge at compilation time, and a real PITA for developers having to MAINTAIN code created in a whimsical nano-second of creative joy, but which then has to sit around being maintained and understood for years after that not-that-much-more-brief moment of labour-reduced intensity) .
With the ability to declare variables whilly-nilly and hither and thither, where is the poor maintenance developer to go to seek out that declaration? They have to go spelunking (or invoke yet more IDE scaffolding).
I agree that garbage collection isn't a good fit in Delphi. But there are occasions when the compiler could be coerced into taking the drudgery out of our miserable existence as developers without involving the overhead of reference counting.
Some time ago I suggested co-opting the existing but now long since out of use "automated" keyword to mark a local variable (of object reference type) as following the interface type semantics.
procedure SomeProc;
var
list: TList automated;
begin
list := TList.Create;
end;
The "automated" keyword would simply direct the compiler to:
- initialise the variable as NIL
- call "Free" using the object reference when the variable leaves scope
Currently interface reference type variables follow an almost identical pattern:
- initialise the variable as NIL
- call "_Release" using the interface reference when the variable leaves scope if the reference is non-NIL
(note that for object references the non-NIL test is redundant as it is handled by the implementation of Free, which is already NIL-safe - this is not the case for interfaces)
The same approach could be extended to member variable declarations and, less usefully but for consistency, unit variables (so called - incorrectly so - "global" variables).
This small change would make an immense difference to everyday programming jobs, but equally could be completely ignored by those who enjoy creating try/finally constructs.
(www.deltics.co.nz/blog)
There's lot's more that could be said, but suffice to say at this point that for a "dead" language, Delphi seems still to be doing a lot more than just twitching.