Categories
News

Delphi “Weaver” Beta coming

I am sure everyone is excited about the openness with the Delphi road map (and Prism roadmap), and now they have announced their upcoming beta program for Delphi “Weaver”.

What do we know about Weaver?  Well, we are expecting it will be released mid2009, and have are guessing the version as 2010.  It won’t have the full 64-bit compiler, but it will have a preview I am expecting a command-line only compiler, so no debugger.

It may have the new front end compiler architecture, which sounds like it might get us closer to Delphi Prism syntax compatibility.

So what do you want to see in the new Delphi?  New features?  Bug fixes?  Minor tweaks?  You can make your suggestions on the Delphi User Voice page.  Then we can all vote on them.

8 replies on “Delphi “Weaver” Beta coming”

This is JUST the compiler, not the IDE, right?
OK, here goes:

1. Some way of identifying and linking out unneeded VCL stuff. With every version of Delphi, the executables just keep getting bigger, a bad for us freeware/shareware guys.

2. Fix the WITH statement. There are already some good suggestions out there which reduce complexity and improve readability. And if used intelligently, it even helps in debugging. (Syntactic sugar is what higher-level languages are about, else we’d all be using Assembler.)

3. Local VAR declarations. Conserves namespace.

4. Bring back objects that can be (or behave like they are) created on the stack, with destruction on going out of scope. This was still possible in BP7 (I think it was BP7? Or was it Delphi 1?). The current commonly used workaround using interfaces testifies to its usefulness.

Two personal quirks:

5. A switch to enable case sensitivity.

6. Local BEGIN END blocks allowing local scoping.

Ken Knopfli:
>> Bring back objects that can be (or behave like they are) created on the stack, with destruction on going out of scope. This was still possible in BP7 (I think it was BP7? Or was it Delphi 1?). The current commonly used workaround using interfaces testifies to its usefulness.

did you read Marco Cantus solution for this ?

There are already two ways you can do objects that allocate on the stack. (1) descend from TObject – just like you did in bp7 or (2) declare it as type record if you don’t need inheritance.

I am not necessarily the author of the class and inheritance.

I am aware that these tips were intended to help, and thanks for that. But I need Delphi to help me focus on programming a solution, not workarounds, so hopefully someone’s listening.

The complexity of targeting multiple platforms with the same code base has been discussed in detail so often, I’m astounded how many votes multiplatform is getting.

Perhaps this is it a good sign; lots of young programmers have moved to Delphi? I wonder how many that voted have really tried it. I have only used FreePascal once, many years ago, so perhaps there’s some wonder tool bundled with it now. But coding for Windows and Linux using CLX and Kylix taught me a lot about the futility of the exercise.

(I am posting my comment here because I can view the first page of UserVoice.com but our company Access Control blocks everything else.)

I hope they will keep Delphi language as far as they can from Prism. Hoffman *doesn’t* know how to develop a language – it just adds as many as reserved words he can to make it “fashionable”. He changes old Pascal syntax “just because”. Delphi can’t become a pure OO language, thereby going after Prism will just add a lot of useless stuff (like the “method” keyword). If Prism becomes the driver, CodeGear will lose another good slice of Delphi developers – many of those using it much more alike C++ than Visual Basic. And many of those waiting a 64 bit compiler – another delay may not be acceptable.

They are going to move Delphi again to an overcrowded area – instead of covering less crowded niches. Another bad move. And sorry, Hodges at R&D will be another disaster. They’d need someone with a real vision, and Hodges lacks it.

Comments are closed.