View Poll Results: Worth upgrade?

27. You may not vote on this poll
  • no

    7 25.93%
  • yes

    20 74.07%
Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: Delphi 2009 "Tiburon", a worth upgrade since D7?

  1. #21

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    As far as i know, yes.

    I recall some codegear page showing off the differences between Delphi 7 Pascal and Delphi 2007 Pascal. There were loads of improvements like operator overloading and static fields AFAIK.


    Ah here it is:

    And Static fields seem to be on the list. Only they are called "Class Const".

    Classes can now have class constants -- a constant value associated with the class itself and not an instance of the class.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  2. #22

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    Oh crap, man, I didn't even know there are such features in Delphi! :shock: Well, now I'm entirely sure that Delphi's stomped C++.

  3. #23

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    Actually I don't think a class constan covers static field. Some static fields can be changed.
    However just below it says, that class vars is introduced as well. Can't believe, I haven't discovered them before
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  4. #24

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    This week the Euro prices for a Tiburon update are known. The prices are luckily not euro=dollar anymore, but still quite high (low Eur 300s iirc)

    OTOH, there are several things I need an upgrade for:

    (the good stuff, private)
    - I'm still at D2005, so miss some of the stuff of D2006. (fastcode in RTL, 16-byte aligning, SSE2 instructions, better optimizer)
    - unicode
    - generics No fancy stuff, just containers.
    - More FPC compability. Not only exit() but there is also a directive that enables pchar() like behaviour for other pointers, like FPC had forever.
    - At least they have a version with real new features then. It is not just useless .NET me tooisms (don't care for anonymous methods, typing is never limiting)

    That seems trivial, but when reusing FPC code (I converted parts of fpimage) that would save a lot of time.

    (the bad stuff,private)
    - the price. I only use my personal delphi copy for an occasional commercial project, and I barely earned back the initial price.

    (the good stuff, for in my job)
    - Do I really need unicode? The few forms I have at work might be translated the old way.
    - Have D2006 licenses at work already.
    - generics is always nice, specially for containers. If it works decently on value types even for more maybe.

    (the bad stuff, work)
    - price not so much of a problem, if there is real progress.
    - Need compatible free version though, to pair with the paid for one. We still use D2006 instead of D2007 because of Turbo Delphi (most of our apps are TD compat with runtime instantiations), because we install TD's occasionally at customers. It is quick, painless, and don't care about licenses. Sometimes we also give source of minor utils that interface with our apps to customers with a copy(link) of TD.

  5. #25

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    Generics: Great! Wonderful! This is something that Delphi has needed for a long time now.

    Unicode: Same.

    Anonymous methods: Umm... I don't get it. I've seen the explanation various times in various ways, and I still don't get it. What's so special about them?

    Oh well. 2 out of 3 ain't bad.

    What I'd really like to see, though, are improved properties. Properties are set up to look like variables to the programmer, but they don't look quite like variables to the compiler, which creates some really awkward situations. My two pet peeves are read/write properties and array properties.

    Read/write properties: It's not at all uncommon to declare a property that looks something like this:
    [pascal]property number: integer read FNumber write FNumber[/pascal]
    Basically, this is an OO-stylistically-correct way to expose a properly-encapsulated private variable, and the net result is the same as if you'd simply declared it as a public variable. Sometimes you don't need any more encapsulation than that, and gettor/settor methods would just get in the way. (This was one of the things I hated about C++.)
    Problem is, the net result is only the same as if you'd simply declared it as a public variable until you try to pass your not-quite-public-variable to a var parameter. Then the compiler chokes on it. "Left side cannot be assigned to." Is there any good reason why not? It's a read/write property!

    There are two possible fixes which immediately come to mind, and I'd like to see both of them implemented. First, allow the following as valid syntax:
    [pascal]property number: integer read write FNumber[/pascal]
    This would be the simple way, and do exactly what it looks like. Passing this property to a var parameter would simply pass the variable it points to.

    Second, if the read and write parameters are separate, have the compiler automagically do what we all end up having to do manually in this case: allocate a temporary variable of the appropriate type, retrieve the property's value from read, pass the temporary variable to the function, then after it returns, send the temporary copy to the write parameter and deallocate the temporary copy. It really shouldn't be that difficult, now should it? Which brings me to the other thing that's more difficult than it should be:

    Array properties. The way array properties are currently implemented makes perfect sense, as long as you accept the rather absurd premise that your objects will never contain any data members that are actual arrays! Yes, there have been times when I've used array properties to "fake it" and make something that looks like an array where a real array didn't exist, but they're very few and far between. For all the rest of the array properties that refer to real arrays, we're stuck with the primitive C++ style practice of writing gettor and settor methods even if all we need is direct access. And if you declare an array type, and simply declare your array property as that array type, you still can't do a lot of useful things with it, such as change the length of a dynamic array, (at least not without some horribly convoluted code!) because of the var parameter issue!
    Honestly, would it really hurt that much to allow the following as valid syntax?
    [pascal]property myArray: array of TMyObject read FMyArray write FMyArray[/pascal]

    Also, array handling is a bit awkward in general. For example, if there's an easier way than the following to append a new value to the end of a dynamic array, I'm not aware of it:
    [pascal]setLength(myArray, length(myArray) + 1);
    myArray[high(myArray)] := value;[/pascal]
    It would be a bit simpler if we could do it like this:
    myArray[high] := value;[/pascal]
    Although, to be fair, generics will make it a trivial task to write a simple "AppendArray" function that can be written once and forgotten about, so that's not as big a deal now as it used to be.

    Anyhoo, that's my rant for now. What do the rest of you think?


  6. #26

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    MasonWheeler, I pretty much agree with all you said, except for the array property part

    I think that Object FPC(the object pascal dialect of FPC) allows you to pass "property variables" as function arguments with the var directive. I hope Delphi would get that too
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  7. #27

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    Yeah. FPC is way ahead of Delphi in a handful of language-syntax areas. Problem is, I can't use FPC because I need the ability to use packages, which Lazarus doesn't support yet.

    Also, out of curiosity, where do you disagree with me about array properties?

  8. #28

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    Quote Originally Posted by
    Nevertheless, if there are any Delphi developers still hanging on to Delphi 7 (the last version with the old IDE), perhaps these important language changes along with what is now a mature new-generation IDE will be sufficient to persuade them to migrate.
    From brazil (:

    Pascal pownz!

  9. #29

    Delphi 2009 "Tiburon", a worth upgrade since D7?

    Reading around I found this:

    As was mentioned, anonymous methods are a step toward some kind of LINQ-like functionality. However, my ultimate goal is to use this underlying mechanism for increased parallelism both in terms of a library-based solution in the near-future and ultimately as intrinsic parallel-computing functionality of the language itself.

    Building the foundation is the first step in building a house.

    Allen Bauer. CodeGear/Embarcadero Chief Scientist.

    Now that sounds really interesting, and would explain what those anonymous functions are for.

Page 3 of 3 FirstFirst 123


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Comodo SSL