Another list of D2005 Trial Impressions

From: Kristofer Skaug (ya.ierfgnf_at_thnxf.x)
Date: 11/23/04 

Date: Tue, 23 Nov 2004 01:52:22 +0100

I couldn't resist, so I downloaded D2005 Architect Trial and gave it a
5-hour twirl this afternoon.
Before you ask, I'm running on WinXP Pro SP1, P4/1700MHz, 512MB RAM.

1) Install itself went smoothly, Win32 Personality only. Surely didn't
take an hour.
    Even the download (460MB) was less than an hour.

2) Startup/Load time: within 20 seconds, no worse than D7.
    (again, this is Win32 only).

3) General IDE responsiveness: Not superfast, but not as slow as some
others have reported.
    I find this IDE quite usable in terms of "speed of turn".

4) IDE Crashes out on *every* shutdown (File | Exit ... -> ):

  ---------------------------
  Application Error
  ---------------------------
  Exception EAccessViolation in module dotnetcoreide90.bpl at 00034264.
Access violation at address 53054264 in module 'dotnetcoreide90.bpl'.
  Read of address 00000004.
  ---------------------------
  OK
  ---------------------------

This is 200% reproducible in my environment (see above).
Reported as QC9584.

5) IDE Tweaks: First thing I did was to "undock" everything to get my
beloved floating forms back.
    Big sigh of relief that this works!
    Also: Classic color scheme, can't live (or code) without it :-)

6) Question: Can I turn off line numbering in the editor?
    This is not BASIC, you know!

7) There's a tremendously annoying salmon-colored (in Classic color
scheme) "current line" highlighter...
    Can it be disabled? Has this to do with SyncEdit?
    It's continuously getting in my way! Argh!

8) I like the new HTML-based Help insight with declarations shown for
function arguments
   and return types. However:
   a) the hyperlinks do not seem to work for type declarations most of
the time.
   b) Occasionally help insight just reverts to the old non-HTML style
(yellow hint-windows).
      So it's a bit hard to understand what to expect...

9) Ran my D7 Library DUnit test suite on it, it all compiles (after
minor tweaks
  related to my "un-readiness" for D2005) and runs OK!
  To be precise: 418 of 424 tests passed.
  The failures were probably not D2005's fault (needs checking).
  BIG THUMBS UP FOR THIS! (*Yay*!)

10) Saw some strange new compiler messages though:

a) Symbol SysUtils.faVolumeID is deprecated - WTsucc(E)!?

b) W1012: TD:=$E000000000000000; -> Const expression violates subrange
bounds
    TD is an Int64.
    This warning was not raised in D7.
     I'm not so sure it should be, either.

c) H2365 Override method Test_TSsbvFile.Setup should match case of
ancestor TAbstractTest.SetUp
   SinCE whEN was DElPHi A cAsE SensiTIVE laNgUAgE?
   [worse yet, there seems to be no Project Option to turn this message
Off, except turning off all hints???]

d) H2443 Inline function 'FileIsReadOnly' has not been expanded because
   unit 'Windows' is not specified in USES list. [also seen for
'DeleteFile']
   OK, FileIsReadOnly comes from SysUtils.pas but apparently depends on
Windows.pas.
   But I didn't ask for this function to be inlined - Borland did.
   So now I have to insert {$INLINE OFF} around every call to
FileReadOnly, just to
   get rid of this message? Or ... allow more bogus units in my uses
clause that OPxperts'
   "unused units expert" will bark at (when it becomes available for
D2005, that is...)
   Why did Borland inline this? I don't see this one as being a
performance booster.
   There seems to be no project-level option to turn this hint off,
either.
   ... Is there a global option to turn off Inlining at project level?
   If so, how?

11) Feeling adventurous, I decided to try out this new & exciting
refactoring stuff.
The first thing I could think of was extracting a body of code from a
loop:

procedure TForm1.FormCreate(Sender: TObject);
var i:integer;
begin
  for i:=1 to 10 do
  begin
    Caption:='Tell me: '+IntToStr(i);
    Application.Title:=Caption;
  end;
end;

Select Refactorings -> Extract Method ->

Delphi suggests the following refactoring:

procedure TForm1.ExtractedMethod(i: Integer);
begin
  begin
    Caption:='Tell me: '+IntToStr(i);
    Application.Title:=Caption;
  end;
end;

(hmmm, a bit weak that Delphi doesn't strip off the begin-end block)

Refactoring in progress... (cool Rubik's cube animation BTW!)... then...
*** BAM! ***

[X] An unhandled exception has occurred in a component in your
application.
Click continue and application will ignore this error and attempt to
continue.

Reported as QC9586.

Drat. The single most interesting function in the Refactoring armory
crashes on the simplest and most benign attempt to use it! :-( !!
Where do I go from here, how can I trust Refactoring to work after this,
and not mess up my code?

Listen Borland, since all the good stuff in D2005 was pre-announced at
BorCon, I would happily have waited another 2-3 months for this release,
with the prospect of less embarrassing bugs. Then I could have made a
convincing case that we should upgrade. This product is so "fresh" that
you can find a handful of bugs within two hours' playful use... some of
the new features sound/look promising, but my confidence in the
Refactoring tools is reasonably shaken already, after getting crashed-on
within 1 minute of attempted use. For now, the most positive experience
of using D2005 was that it was able to compile and run my existing D6/D7
code. That's great, but D6 can do that, too. To be worth it, I expect in
D2005:

a) Bug fixes vs D6/D7 (I'll be looking for those in the coming days,
    running through my QC lists).
b) New features vs D6/D7 *without* a load of new bugs

At the current state of play, and taking D7's patching history freshly
(or stalely, as it were) in mind, there's no way I could bring myself to
recommend spending somewhere between 5K and 10K Euro's to get D2005 for
my development team. Yep... looks like it's back to D6 for the time
being... 

-- 
Kristofer

Relevant Pages

  • Re: trouble creating array of objects
    ... >>You can stop when sufficient bugs are squashed. ... > might try refactoring, but I would preserve the original in case I had ... > what the code does or how it does it, I lean to rewriting. ... Often there is a lot of encapsulation, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: OO Software Project Entropy Question.
    ... > the project may tend to spend more and more time fixing bugs. ... If a team implements features in small batches, such as 5 features a week, ... There are those who decide that "refactoring" is re-work. ... Design Smells are errors in design - not bugs. ...
    (comp.object)
  • Re: creating methods for objects
    ... then converting it to a lower level language. ... As the Ruby code grew, I attended to its design, and refactored to ... While refactoring, I ran all the tests every ... only bugs I found were in the immediate feature I worked on. ...
    (comp.lang.cpp)
  • Re: How many lines of code per programmer-hour?
    ... Derek Davidson wrote: ... and proposed that perhaps refactoring to a stage where supporting new ... The best way to bug Borland about bugs. ...
    (borland.public.delphi.non-technical)
  • Re: Code Coverage and QC
    ... >>changing behavior. ... Fowler's Refactoring ... trying to fix a specific bug, ... I introduce no bugs and fix no bugs. ...
    (comp.object)