Mega Code Archive

Whats new in Diamondback (officially called Delphi 2005) Includes Sneak Peek

Title: What's new in Diamondback (officially called Delphi 2005) - Includes Sneak Peek Question: Diamondback is the next version of Delphi (Officially Delphi 2005). It will target .NET 1.1. Answer: is official, Delphi 2005 is out, seems like the summary I put here is pretty good... anyway, here's a white paper with nice screen shots of the different features Whats New in Delphi 2005? more news, Delphi 2005 trial version is available for download, you can get it here: Delphi download Homepage I have put a document together with all the information that is scattered around in the Borland guys blogs I'll keep updating the article as more information comes out First of all, here's the sneak peek, so you can actually see it in action!!! and see some of the things in this article, if you have no idea what they mean, here's where you can see it Diamondback Sneak Peek The sneak peek is about 15 minutes long and includes: - Welcome page with news feeds - Multi-personality IDE for Delphi/Win32, Delphi/NET and C# - Project groups with Delphi/Win32, Delphi/NET and C# projects - Error insight - Help Insight - Refactoring - History View - For..in..do - Supported in Delphi/Win32 - Supported in Delphi/.NET "The aim of Diamondback is to make the ultimate Windows development solution for our Delphi customers. It's not about one thing versus another, it's about developers, and building great apps for Microsoft Windows." Diamondback = .NET 1.1 - Officially confirmed: Diamondback will support - Delphi for Win32, - Delphi for .NET, - and C#, all within the same IDE. - You'll even be able to put Delphi and C# projects into the same project group. - The current personality you are using is indicated by the icon. - IDE - The IDE allows you to have several different type projects in one project group, and enables you to switch between them without closing the IDE. - IDE is theme-enabled! Transparent panels & checkboxes, even at design time - IDE uses VirtualTreeView - IDE look & feel improvements: Object Inspector, tool palette - Delphi Direct goes away. Instead, the BDN news feed appears on Welcome page. - You'll be able to add your own feeds - Built-in IDE QualityCentral reporting - The CPU view will show the source, the IL, and the x86 code! (Visual Studio can show the source and the x86, but can't show the IL!) - Side note: VCL for Win32 does not do Unicode, and there are no plans to add it. - For people who need Unicode VCL in Win32, they suggested the free TNT controls, and said they have the Danny Thorpe Seal of Approval. - Wavy red underlines for compiler errors; hints showing the error message - Persistent bookmarks!!! (YES!! finally) - Error insight - Expanded real-time error information for source - Integration into the structure view - Help insight - Tool tip from XML doc information - Updated/consolidated new component wizard - Combines all functions of New VCL component/import AX type library/control - Open API VCL designer (.NET and Win32) - Embedded floating - Left/Top properties can be independently set and persisted with embedded - Component palette is drag-and-drop even in VCL - Marketing has always claimed that Delphi supports "drag-and-drop" GUI development, but Allen commented that it was really "click-and-click" - Now you can actually drag a component off the palette and onto the form - Yes, click-and-click development still works. So do double-click and Shift+click. - Demand loading of Win32 design-time packages (Allen blogged about the consequences of this decision, but didn't say what the reason was) - Component Palette in Diamondback probably won't support one component in multiple categories, yet. - Object Inspector shows properties for files and projects. Can rename a file using Object Inspector, even if it's not saved yet! - Carries rename through to the disk file - Doesn't do anything to the old .dcu file (alas) - New Open Tools APIs, including a syntax-highlighting API Find References, Find Local References - Not by name. If there are two different TFoo classes in two different units, this will find only references to the one you selected. (Based on the same metadata as refactoring) - Doesn't go through the compiler, so it's very fast Tool palette improvements - Not just components anymore - File New stuff is now in the tool palette - Incremental search: start typing, filters the list - Can drag categories and items around to reorder them, to optimize the incremental search for what you use most - Ctrl+Alt+P focuses the Tool Palette, so you often don't even need the mouse History view - Every time you save, it rolls a new backup file - You can specify how many levels of backup to keep - Diff between versions - There will be some level of integration with StarTeam here (but not in the build he was running) - If you had 30 revs of a file, and you change the setting to only save 10 revs, it will not delete the old revs, and will continue to keep 30 revs for that file. - Diamondback will have solid StarTeam integration - Browse & open directly from repository - File renames are tracked on server - D8 Enterprise already ships with a StarTeam Standard license Debugger improvements - Multiple debuggers - Debugger registration - Connect to IIS better - Intelligent mode switching - Better evaluators - Same operations in both debuggers - CPU View Debugging features - Debug .NET code hosted within a Win32 process - May not be able to seamlessly "Step Into" from Win32 code into .NET code - AppDomain support in Module view - Better stack traces in Win32 for frames without debug info. Think EnumFonts; you didn't used to be able to see a stack trace when Windows calls your callback function, but now you will. - Locals view and stack frames: Yes, it will work even after exceptions! Woot! - Look at different threads' call stacks and Locals views - Same operations in both Win32 and .NET debuggers Refactoring - Rename (variables, methods throughout all your code) - Rename Class refactoring even reaches into the .dfm - Also, if you rename a form class, it will rename the global Form1 variable in that unit - Extract Method (select a few lines of code and automatically create a new method) - Knows when to, and when not to, use var parameters - Don't know whether it can do out parameters or function returns - Extract Resource String - Picks a default name for the resource string - If that name already exists, reuses the existing resourcestring - Sync Edit (select a block, hit a button, and it underlines all the duplicated words; click on one and start typing, and it syncs with all the others within the block) - Sync edit: Can Tab through distinct symbols - Find unit or namespace - Declare Field - Declare Variable - Right-click on an identifier, select "Declare Variable" - Smart guesses a reasonable data type - Shows a preview of what's going to be changed, and doesn't apply until you say go - All of these work in Delphi for Win32 and Delphi for .NET - All except Extract Resource String work for C# - Unsurfaced Refactoring API, so there will probably be more refactorings in later versions - No distributed refactoring in Diamondback, but they have underlying architecture to support it - Refactoring works across projects within a project group, even between C# and .NET - Based on actual uses list, not just what's in the .dpr - Only works within current IFDEFs - "Live Templates" (Ctrl+J templates with this Tabbing to fill gaps) won't be in Diamondback but are on the plate Multi-unit namespaces - Goal: Put symbols into a specific namespace while preserving unit make logic (which works by having a relationship between the unit name and the file on disk) and the syntax and the package support - Relationship between assemblies and namespaces is many-to-many - There is no relationship between the namespace and the file on disk - uses Namespace; always refers to a namespace, never to a filename - In Delphi 8: (the old way) - Unit name = .NET namespace. This works as an interim solution, let's get it shipped. - Problem: Exposes structure to the world. Component and library authors want to split code into multiple files, but that's a pain for their customers. - More segregated than most .NET namespaces - Can't inject code into a namespace you don't control (not that this was necessarily recommended practice to begin with) - Diamondback: (the new way) - unit Borland.Vcl.Classes; - Rightmost segment is dropped. Types in this unit end up in namespace Borland.Vcl. (Borland.Vcl.TList) - Rightmost segment of unit name is just disambiguation for the compiler, not for .NET namespaces - 'Classes' is still there behind the scenes (buried in the metadata), but it's not in the C# programmers' face - All interfaced symbols in units "a.b.c" will be emitted into the namespace "a.b" - so File A.B.C.pas used to go into namespace A.B.C, but will now go to namespace A.B - New convention for globals: global Foo in A.B.C.pas is now A.B.Units.C.Foo - The unit class that stores global variables and global procedures is named "a.b.Units.c" - uses Borland.Vcl.Classes; - Compiler can find file on disk by appending '.pas'. - Compiler can also find this unit within a package, and only pulls symbols for that single unit. - This is using a unit, not a namespace. - uses Borland.Vcl; - This is using a namespace. - Only works for code that's already compiled into an assembly. Cannot work for static linking (because there's no way to find the .pas file). - Wide open; pulls in everything in the namespace, not just one unit. - uses Borland.Vcl.*; - This is either using a namespace, or using multiple units specified by a filespec. They amount to the same thing. - Works against code in packages, and against source/dcus. - Be careful. If you're going against source, this loads a lot of symbols from disk. (Compilation will be slow.) - The smart linker will be even smarter for this. If a unit is dragged in by the wildcard, but you don't ever reference any of its types, then its initialization section will not be compiled into the EXE. - This is here for completeness. Danny doesn't recommend using it normally. - Globals (global procedures/functions, global constants, global variables): - Borland.Vcl.Classes.MyGlobal becomes Borland.Vcl.Units.Classes.MyGlobal. - The 'Units' is stuck in there because Delphi already allows a global named 'Classes' inside the unit named 'Classes'. - Simple unit names (no dots in the filename) are an exception to this rule. When the rightmost segment is in fact the only segment, it's not dropped. - But if the project has a default namespace, it's considered part of the filename. - So if the default namespace is Borland.Vcl, and the file is Classes.pas, then the "fully-qualified filename" is considered to be Borland.Vcl.Classes.pas, so the Classes is dropped. For..in..do - Loops over the elements of a collection, without actually requiring you to care about indexing into the collection - When is it useful? - When you don't care about the index, but just want the elements - When you don't want to do an indexed loop because getting a count and/or doing random access is expensive (linked lists, database tables) - Danny gave the example of asynchronous retrieval (a background thread is going out and getting the next element before you ask for it), which doesn't work so well with array indexes - Unordered / non-indexed data (sets, hashtables) - You should think of the returned data as read-only. Do not change the collection while iterating. (You can change properties on the object you got, but don't try to replace the object in the collection) - Modifying the underlying collection should cause the enumerator to throw an exception the next time you call MoveNext. (So don't modify the collection while you're iterating!) - Win32 implementation may allow writeback someday, but it might be full of gotchas. Assume that you should never modify the collection while you're iterating it. -Because you treat the data as read-only (you are treating the data as read-only, right?), an enumerator should give you a stable view of the data. - That means that, if you call Reset on the enumerator, and enumerate a second time, you should get the same data. - Not guaranteed to be in the same order the second time, though. - This is the theory. In reality, things like databases may not guarantee a consistent view, for performance reasons (because doing a read-only transaction might be cost-prohibitive). But if they did offer a consistent view, wouldn't that be nice? -Syntax: for MyObject in MyCollection do { statement }; - Why not foreach? - Because Danny was reluctant to add a new keyword - Besides, should it have been 'foreach' or 'for each'? - As a mathematician, Danny asked, "Wouldn't 'for all' be better?" - So, no new keywords for this. - Supported in both Win32 and .NET - .NET uses IEnumerable if it's there, otherwise looks for the code pattern - Win32 only supports the code pattern (probably because interfaces carry all that reference-counting baggage) - The collection is held in a temporary variable. - So, if you did for MyRecord in LoadCollectionFromDatabase do, you'd still be fast, because LoadCollectionFromDatabase would only be called once. - Much like the way the for loop already caches its maximum value. - Collection must fit one of these: - Implement IEnumerable (.NET only, for now) - Have a method called GetEnumerator - Be an array, set, or string (or enumeration? Danny didn't remember for sure) - Mechanics: (very familiar if you already know how C# does foreach) - GetEnumerator returns an enumerator object, with MoveNext and Reset methods and a Current property - You start with no current element (on a "crack", per Danny) and must call MoveNext to make the first element current - MoveNext returns False when there are no more elements (if the collection is empty, it returns False the first time you call it) - Reset rewinds the collection to the beginning. for..in does not call Reset. The enumerator is freed automatically at the end of the loop (inside a finally block). - Many classes in the VCL will support for..in. - Not all, because when generics come out, they'll all be generics and it will only need to be implemented once - VCL classes (and descendants) supporting for..in - TList - Tollection - TStrings - TInterfaceList - TComponent - TMenuItem - TCustomActionList - TFields - TListItems - TTreeNodes - TToolBar Function inlining - think of inline as calling convension, like stdcall, register etc. inline calls work in a way that no call is made, but body of code is copied inside caller. But, it is just a hint, so compiler may not inline, but call in standard way. - Involves persisting the compiler's node tree to the .dcu. Not been done before. - Can produce significant speed boost in certain cases - Caution: Code bloat risk! - Not quite like C macros, because these aren't textual replacements instead, it grafts nodes into the syntax tree (it's after parsing, not before) - Works for most anything: procedures, functions, methods, and local procedures - 'inline;' directive, looks like a calling convention - Works for both Win32 and .NET (and may beat the JIT compiler in some cases, since the JITter goes for fast optimizations and low impact) - The compiler can refuse to inline a function: - The 'inline' directive is just a suggestion to the compiler. The compiler can disregard it if it thinks you're wrong or stupid. - Could decide it would make the call site too complex (by needing too many temps and blowing your registers) - The same procedure may be inlined at some call sites and not others - This is still a top-down compiler. It must see the body of the inline procedure before it's used. In some cases with circular unit references, the compiler disables inlining on purpose. - Doesn't work for procedures with an asm body, because that doesn't emit compiler tree nodes - Spliced into node tree before optimization - Generates temps for stuff that's passed into the procedure - Then probably optimizes those temps right back out - Restrictions on inlining stuff that access class privates - Hard and fast rule in .NET: Can't inline these into another class - May relax this rule in Win32 code, post-Diamondback - Best practices: - Use only for very small functions - Always test performance and measure the benefit don't assume it will speed up your code. It may slow it down! - Several caveats - Compiling the other unit at the same time as compiling the call site (build all) is a different situation than inlining a function that was loaded from a precompiled .dcu" (though it's not clear what that means) - Looks like this is mainly for the functions in Windows.pas. It's not clear how useful it will be for user code. - Hidden temps; burns registers and stack - Can actually hurt performance - Causes unit dependency brittleness: users depend not just on your interface, but also your implementation. May not matter much for our code, but for this reason, expect Borland to be very conservative about using inline within the RTL and VCL! - {$INLINE ON/AUTO/OFF} directive - Affects the call site - AUTO = compiler picks "small routines" to inline. Per Danny, this option is "scary" and will never be the default. A couple of interesting digressions - Arrays in .NET can't be preinitialized, so if you have a global const array, it's actually initialized in code in the unit's class constructor (note from original author:I'll have to reread the IL book I know there is global data, since that's where strings are stored, but evidently it can't be used for arrays) - Note on unit initialization sections: If you have circular unit dependencies, the initialization order may not be the same between Win32 and .NET. This is because, when unit A touches something inside unit B, unit B's class constructor will fire immediately in .NET, whereas in Win32 the initialization section might not fire until later. - Class Helpers - Syntax trick injects an additional symbol scope into member lookup - Allows injection of names into class type scopes that you cannot modify - Potentially dangerous: subverts sealed and final contracts of original author - CREATED ONLY FOR THE PURPOSE OF MAPPING DELPHI'S RTL/VCL OBJECTS ONTO .NET!! - VCL - New components (TButtonGroup and TCategoryButtons: used as basis for new palette) - Better encapsulation of IE WebBrowser component - New TCaptionedDocTree (Doc tree used in IDE) - Various Windows "macro" functions now inlined - New design time support for Help text in Object Inspector - New design time support for hot-link pane in Object Inspector - Support for enumerator syntax - Data Explorer - Data migration - Drag and drop stored procedures and automatic parameter population - Metadata services - Create table - Alter table - Designers and Wizards - Stored procedures dialog - Table mapping dialog - Stored procedures drop down list - Schema Name drop down list - Typed datasets (.NET) - Compile to standalone assembly - Support datasets from web services - Relations and table editors - Properties dialog - SQLConnection string editor - BDE for .NET - Dynamic loading of DLLs without path - Blob performance improvements - TUpdateSQL - TNestedTable - TStoredProc - dbGo for .NET - Migration of ADO support from Win32 to .NET!!! - What Diamondback will NOT have - Diamondback will not have any of the new .NET 2.0 features. It will target .NET 1.1. - Still no way to put VCL controls on WinForms - You can compile against .NET 2.0 today in Delphi 8. There's a compiler switch that lets you specify which runtime version to target. - What might be added for Win32 (After DiamondBack) unofficially called "Whidbeyish Diamondback+1". - Whidbey support (well, yeah, you can compile against Whidbey in D8, but you can't consume generics so you're really a second-class citizen) - Nested types - Record Methods - Records with methods in Win32: Will be there primarily because they're a prerequisite for operator overloading. - Operator Overloading - Operator overloading in Win32: Will only be supported for record types. - Custom Attributes - Parameterized types - Generics - Multicast Events - On generics and Win32: - Generics may exist with restriction that T must be an interface (or maybe a class) - Don't know whether generics will be in first 2.0 release - Parameterized types (code example preview) Type TList = class data:array of t; procedure Add(item:t); function Extract(item:t):t; end; procedure TListAdd(item:t);... - The version after Diamondback will support .NET 2.0 new stuff, and will come out about the same time as Whidbey ("summerish" 2005). - .NET 2.0 Delphi will support generics and type inferencing, and may even push the envelope. - .NET 2.0 Delphi will probably have to support partial classes, because ASP.NET 2.0 requires them. - Delphi generics may work on Win32, but will probably only work with interfaces and maybe classes. - Pointless side note: The Delphi/Win32 compiler has a NativeInt type. Don't use it. It's going away. - Delphi for .NET will support 64-bit processors, but VCL for .NET does not - In 64-bit, OS handles are 64-bit - There's still some code in VCL that has them as Cardinal - As part of the fix, compiler will probably add warnings if you try to assign a handle into a Cardinal or an Integer, so third-party code can be fixed easily Side note about KYLIX! Remember Kylix? Believe it or not, Michael Swindoll has just announced that Borland has initiated the Kylix Community Project. The admin team for this includes Borland and key members of the Borland Community (including Chad Hower) with the goal to update the CLX library. have you heard the "Is Delphi dying?"... here are some answers from Borland: "[We will] never abandon the developers" "[We're] focused on developer productivity" references: BorCon2004 Wiki Allen Bauer Craig Stuntz Danny Thorpe Jim McKeeth Marco Cant Nick Hodges Robert Love Paul Gustavson Joe White Comments are welcome best regards EberSys