PDA

View Full Version : Delphi 2009 "Tiburon", a worth upgrade since D7?



arthurprs
03-08-2008, 06:29 PM
New Language Construct for Exit
Full Unicode supports
Generics
Anonymous Methods
[..] another things

and all things included on previous delphi
inline support
recods with methods
operator overload
class constants
for in (iterators)
etc..

generics and anonymous methods:
http://blogs.codegear.com/davidi/2008/07/23/38915
new exit:
http://blogs.codegear.com/nickhodges/2008/07/22/39079/


what do you guys think?

JSoftware
03-08-2008, 08:22 PM
Good thing with generics support. I would like to see how it's done in delphi. The FPC implementation seems a bit dodgy

arthurprs
03-08-2008, 08:32 PM
i edited the first post, see the 1? link

JSoftware
03-08-2008, 08:39 PM
Looks ok. Don't know quite about the usability of anonymous functions which looks like a weird concept to me, but interesting anyhow

arthurprs
03-08-2008, 08:50 PM
Looks ok. Don't know quite about the usability of anonymous functions which looks like a weird concept to me, but interesting anyhow

same here ;p

Robert Kosek
04-08-2008, 01:08 AM
Good thing with generics support. I would like to see how it's done in delphi. The FPC implementation seems a bit dodgyI made a generic list in FPC, and it's not so much dodgy as the current "stable" release has a few critical bugs only fixed in the development releases you can get with Lazarus. (IE, don't JUST get a dev copy of FPC, it isn't new enough unless packaged with Lazarus.) It's also got a few wacky limitations that I can't remember any more, like no more than 1 anonymous part. Like you can't do "TGenericStringIntList" or something.

cronodragon
04-08-2008, 02:01 AM
Now exit works like return in C, nice. But creating procedures on the fly seems a little contradictory to reusability...

Which .NET versions D2009 will support?

marmin
04-08-2008, 06:31 AM
Still not multi-platform? :P :drunk:

chronozphere
04-08-2008, 08:35 AM
Now exit works like return in C, nice. But creating procedures on the fly seems a little contradictory to reusability...


Wow.. that's awesome :D That WAS one of the few things i disliked about pascal (absence of a return *returnvalue* construct).

NecroDOME
04-08-2008, 09:39 AM
I really like the generics support :) . I'm looking forward to this one!

arthurprs
04-08-2008, 11:55 PM
pool added, lets vote

czar
05-08-2008, 07:27 PM
I think I will stick to delphi 2007.

Almindor
06-08-2008, 07:26 PM
Don't want to sound like a troll here but you do know that FPC had Exit(value) for ages now right? :)

On the generics thing, yes, FPC generics are bugged and incomplete, but they are "alpha feature", mostly there for people to see/test and criticize.

JSoftware
06-08-2008, 08:03 PM
Don't want to sound like a troll here but you do know that FPC had Exit(value) for ages now right? :)
I knew it had it, but I don't use it after an experience once where a piece of code containing such an exit statement exerted some strange behaviour. Can't reproduce it though, so no help there :)



On the generics thing, yes, FPC generics are bugged and incomplete, but they are "alpha feature", mostly there for people to see/test and criticize.
I like the FPC implementation to some degree. I think it would be awesome if you could sacrifice some of the strictness and let people declare new generics classes in runtime

like:
function GetMatrices(const quats: array of TQuaternion): TList<TMatrix>;
begin
result := TListConverter<TQuaternion>.Create(quats).ConvertToListOfMatrix;
end;

Another thing: "Warning: Global Generic template references static symtable". Does that mean something that I should be afraid of?

Luuk van Venrooij
08-08-2008, 07:28 AM
Sounds like some new cool features, but I also would like to see multi platform support. Personally I think that since D2006 was pretty much on the right track for worth updating since D7. It had still a lot of bugs though. D2007 I think was a must update for vista developers like myself.

Robert Kosek
08-08-2008, 12:51 PM
On the generics thing, yes, FPC generics are bugged and incomplete, but they are "alpha feature", mostly there for people to see/test and criticize.I'll disagree there, the only bug I found was in the stable release--where it was practically a pre-alpha feature. In the latest lazarus development release the generics support is much better, even though I, like Traveler, wouldn't mind it being less strict. ;)

Brainer
09-08-2008, 10:52 PM
I'm really looking forward to the new Delphi, now I use D2007 and I'm very pleased of it, it has everything I need. It's amazing that they decided to implement generics - now it feels like Delphi finally got stronger than C++ or at least it's as strong as C++. ;) Those anonymous methods are weird to me - what's the use of them, really? :? A new Exit method - I guess I don't need it - I use my own logging class and that's enough for me. :P

Correct me if I'm wrong, does Delphi have static fields? I'd like to see them in D2010 or whatever (ofc if they aren't present yet). ^^

pstudio
10-08-2008, 12:23 AM
How can you be wrong when you're asking a question? ;)
AFAIK static fields don't exist in Delphi. I've looked for it on a few occasions we're it would have been useful but with no luck. :(
Does anyone know why static fiels don't exist? Perhaps a limitation to the Pascal language (though I can't see why)?

JSoftware
10-08-2008, 12:27 AM
What do you mean with static fields? Delphi has static(class) members for classes but not for local variables

Brainer
10-08-2008, 04:02 AM
How can you be wrong when you're asking a question? ;)
:lol: Yeah, good point! :)

What do you mean with static fields?For all I know, a static field is a class field whose value is shared between all class instances. F.x.:


class X
&#123;
public&#58;
static int i;
&#125;;

X a, b, c;

a&#58;&#58;i = 10;

And now, all three class instances (a, b, c) have the same value for i.

Is it possible in Delphi?

chronozphere
10-08-2008, 06:56 AM
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. ;)

Edit:

Ah here it is: http://dn.codegear.com/article/34324

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.

Brainer
10-08-2008, 01:32 PM
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++. :)

pstudio
10-08-2008, 03:16 PM
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 http://www.tamemymind.com/blog/images2007/smiley-bangheadonwall.gif

marcov
26-08-2008, 07:47 AM
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.

masonwheeler
26-08-2008, 02:42 PM
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:
property number: integer read FNumber write FNumber
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:
property number: integer read write FNumber
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?
property myArray: array of TMyObject read FMyArray write FMyArray

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:
setLength(myArray, length(myArray) + 1);
myArray[high(myArray)] := value;
It would be a bit simpler if we could do it like this:
incLength(myArray);
myArray[high] := value;
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?

Mason

JSoftware
26-08-2008, 03:10 PM
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

masonwheeler
26-08-2008, 04:08 PM
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?

arthurprs
28-08-2008, 10:23 PM
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.

cronodragon
02-09-2008, 04:52 PM
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.

Source: http://www.reddit.com/r/programming/comments/6tp3i/pascal_gets_closures_before_java_why_hasnt_the/

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