Delphi 2009 (Tiburón) Onizlemesi
Posted by: Sadettin Polat in N-Tier, codegear, delphi, duyurular, genel, ideBloglardan takip edebildigim kadariyla yakin bir zamanda cikacak olan Delphi 2009 (Tiburón) hakkinda ki bazi fikirlerimi paylasmak istedim sizinle.
1- Unicode destegi.
Artik Delphi 2009 ‘un idesi, vcli , compileri herseyi artik unicode destekli. Hatta delphi urun yoneticisi bu durumu vurgulamak icin Unicodified tabirini kullanmayi uygun gormus. Veritabani baglantilari , bilesen isimleri , temel string tipi , mesajlar falan hersey artik unicode. Unicode destegi sizin icin gerekli ya da gereksiz olabilir ama eninde sonunda kacinilmazdi ve delphi 2009 ile bu destek karsimiza cikti. Simdi bundan sonra neler olabilir , ne gibi durumlarla karsilasabiliriz soyle bir liste yapmaya calisalim.
- Delphi 2009 ile yaptiginiz uygulamalar artik win98 lerde calismayacak. Geriye uyumluluk adina bircok seyden vazgececegiz. Aslinda bu konudan cok emin degilim ama unicode degisikliginin compiler seviyesinde yapildigini dusunursek % 99 ihtimal win98 lere artik elveda diyebiliriz.
- Artik cince sitelerde gordugumuz kodlari anlamamiz ve modifiye edip kendi projemizde kullanmamiz cok daha zor olacak. Eskiden string degerler haric geriye kalan ifadeler ingilizce oldugundan kodlari okuyup anlamamiz daha kolay oluyordu. Simdi cinliler herseyi unicode var diye kendi harflerinde yazarlarsa isler arap sacina donecek
- Unicode yillardir alistigimiz ansii karakter setinden cok farkli. Uzun yillardir unicode destegine sahip dillerde bile bircok kisi hala bu karakterlerin duzgun bir sekilde saklanmasi ve gosterilmesi ile ilgili problemler yasarken bu problemleri bizlerinde yasamasi kacinilmaz. Alismak biraz zaman alacak ve bu arada epey bir sac bas yolabilirsiniz.
- Unicode benim cok ihtiyac duydugum bir sey degildi acikcasi ve bu nedenle Tiburon kullanmak su an icin bana biraz luks kaciyor. Hayatimda unicode destegine ihtiyac duydugum sadece bir tane proje gelistirdim onda da TNT nin unicode destekli bilesenleri isimi fazlasiyla gormustu. O nedenle su an icin delphi 2007 ile yoluma devam etmek bana daha cazip gibi gorunuyor lakin urunu canli canli minciklamadan kesin birsey soylemek istemiyorum.
- Temel String sinifi artik unicode bir string tipi oldugundan eski kodlarinizi Tiburon da derlediginizde bazi garipliklerle karsilazmaniz muhtemel olacaktir.
Listbox1.Items.LoadFromFile(’c:\temp\MyListBoxItems.txt’,TEncoding.UTF8)
tarzindaki kodlarinizin duzgun dosya formatlari ile duzgun calisabilmesi icin artik parametre olarak sonuna hangi karakter turuyle islem yapmak istediginizi belirtmeniz gerekebilir. - unutmayin! SizeOf(Char) artik geriye 1 degil 2 degerini donderecek. string = UnicodeString , PChar = PWideChar
2- Object Pascal’a eklenen yeni ozellikler
- Win32 icin Generics metodlar. Generics metodlar hakkinda bilgi icin bkz:1 , bkz:2
- Anonymous Methodlar. Bu metodlarin tam olarak nerde nasil ne ise yarayacagini anlayabilmis degilim. Bizim procedur ve functionlarin icinde kullandigimiz embed metodlara benziyor ama bloglarda verilen orneklerde tam olarak varolus nedenini cikartabilmis degilim. bkz:3
3- Yeni datasnap mimarisi
Acikcasi Tiburonda Datasnap ile ilgili iyilestirmelerin yapilacagi yol haritasinda soyleniyordu ama bu iyilestirmeden oteye gecmis ve karsimiza JSON/RPC tabanli yepyeni bir mimari getirmisler. Unicode olmasa da bu yeni Datasnap mimarisini kullanmak icin bilgisayarima Tiburon kurabilirim. Datasnap artik cok gicik oldugum ve kullanmayi bi turlu sevemedigim COM/DCOM bagimliligindan tamamen kurtulmus. Artik sunucuyu register etmek gibi dertlerimiz olmayacak ve eminim bu yeni mimari cok daha kolay kullanilabilir , basit , sade ama cok guclu olacak. Yeni datasnap mimarisi DBExpress ile icice tasarlarmis. Birbirleriyle iletisimleri ust duzeyde ve datasnap kullanirken dbexpress kullanmak olmazsa olmazlardan olacak gibi duruyor. Bu iki nokta aklima su dusunceyi getiriyor benim. DBExpress zaten yuzde yuz object pascal ile yazilmis bir framework ve platform bagimsiz sayilir. Datasnap COM/DCOM ve midas.dll ortamlarina bagimliydi. Tiburon ile bu bagimliligi kaldirmislar. Yani ileriki bir zamanda CodeGear Delphiyi cross platform yapmak icin onunde bulunan buyuk bir engelden kendini kurtarmis oldu. Bilmem anlatabildim mi ?
Bu kismin eksik kalan tek yanina hala Firebird icin dogal dbexpress surucusunun kutudan cikmiyor olmasini ekleyebiliriz.
bkz:1
bkz:2
4- Com ve ActiveX mimarisinin yenilenmesi
Bu yenilenme tam olarak neleri iceriyor cok net bilgim yok ama en azindan bloglarda yer alan resimlerde Import ActiveX gibi islevler yenilenmis ve biraz daha gelistirilmis.
5- ideye eklenen yeni ozellikler
Component palete bir tane edit ekleyerek daha onceden yaptigimiz bilesen aramasini biraz daha anlasilir ve mantikli bir hale getirmisler. Islev olarak ideye yeni bir ozellik getirmesede Delphi 2007 de o ozelligi kullandikca aklima hep Git dugmesi olmayan internet explorer surumleri geliyordu. Acmak istedikleri siteyi adres cubuguna yazdiktan sonra Entera basmak gerektigini bilmeyen bircok kullanici site acilacak diye dakikalarca beklemislerdi.
6- VCL e eklenen yeni bilesenler…
Bana gore Cagetory Panel haricindeki diger bilesenlerin “dostlar alisveriste gorsun” mantigiyla VCL e eklendigini dusundugum gereksiz bilesenler toplulugu.
bkz1
Sonuc olarak delphi 2007 ve daha onceki versiyonlar ile gelistirmis oldugunuz bir proje icin getirmis oldugu cok ahim sahim bir ozellik delphi 2009 da mevcut degil. Ancak yeni bir proje baslarken Unicode destegini de yaniniza almak ve windows 2000 den öncesine elveda demek isterseniz ya da yeni yaptiklari Datasnap nasil birseymis diye merak ederseniz mutlaka edinmeniz gereken bir surum olmus. Onun haricinde Delphi 2007 ile yola devam etmeniz halinde kacirmis olacaginiz pek fazla birsey mevcut degil delphi 2009 versiyonunda. Hatta bana kalirsa eski projelerinizi baliklama delphi 2009 gecirirseniz unicode ayagina basiniz cok agriyabilir. Bir zamanlar Delphi 3 ten Delphi 4 e gecerken real tipinde yapilan degisikligin zamaninda bizi ne kadar ugrastirdigini bilenler ne demek istedigimi cok iyi anlayacaktir
Entries (RSS)
July 30th, 2008 at 15:04:25
Aslinda UNICODE sac bas yoldurtan birseyse de bir zaman sonra herkes buna ister istemez alisiyor. Acikcasi delphi ile unicode’da pek sorun yasamis degilim ama web formlari, web dilleri ve veritabanı uygulamalarında unicode gerçekten çok ciddi sorunlar çıkarıyor. Burada bir ipucu vermek gerekirse UNICODE ile tam uygun çalışan bir web aplikasyonu yazmak için HTML çıktısının karakter kodlamasından tutun arka planda çalışan dilin dosyaları dahil olmak nihayetinde veritabanı, veritabanı bağlantı tutamacı dahil herşeyi unicode yapmak gerekiyor. Ancak bu şekilde yani tamamen unicode’a terfi olursak unicode sorunlarıyla başetmemiz mümkün oluyor.
Delphi’de A’dan Z’ye unicode desteğiyle geldiğinde -ki gelmek zorunda ve geliyor da- aslında belki ilk aşamada bir takım sorunlar çıkabilecekse de ileriye yönelik olarak (biraz da programcının kendini geliştirmesiyle beraber) hata oranı gitgide düşecek ve karakter seti tabanlı dönüşümler ve veri bozulmalarından doğan emek, zaman ve para kaybı büyük ölçüde giderilmiş olacak.
Bu açıdan bakarsak aslında küçük gibi görünen bir charset olayının (şu an yarım yamalak olmasından dolayı) aslında büyük sorunlar doğuracağını IDE’nin buna built-in destek verecek olmasının bugün ve ilerde doğacak sorunları azaltmak açısından oldukça yararlı olacağını söylemek mümkün.
September 26th, 2008 at 01:32:01
Delphideki Real tipinde yapılan değişikliğin projeyi etkilememesi için {REALCOMPATIBLE ON} gibi bir ifade ekleyerek eski kodumuzu ve data yapılarımızı aynen kullanabiliyorduk.
Bence 2009 ile gelen unicode değişikliğini de böyle küt diye yapacaklarına {STRINGCOMPATIBLE} gibi bir opsiyon koymaları gerekirdi. delphi 2010 gibi ileriki sürümlerde de tamamen geçişi zorunlu tutabilirlerdi. Böylece kolay bir geçiş sağlamış olurlardı. Bana kalırsa bu eksiklik 2009 kullanımında çok büyük düşüşlere sebep olacak.
Şuan elimdeki mevcut bir kodu derlemeye çalışıyorum. Fakat daha şimdiden yüzlerce uyum problemi ile karşılaştım. Yeni projeler için de büyük bir problem var. Alışılmış componentleri nasıl derleyeceğiz ?
Galiba bu unicode meselesi Delphi için çok kritik bir düşüşün başlangıcı olabilir.
October 10th, 2008 at 16:17:12
@Ansugo :web aplikasyonu değil web uygulaması olucak arkadaşım. Türkçe’yi doğru kullanalım. Gelelim Unicode konusuna. Şimdi Amerikan karakter sınıflaması tipi ansi stringleri genişleme özelliğinden mahrumdur dolayısı ile Türkçe’deki ğ harfini kabul etmez. Ama unicode ise harf boşluğunda Türkçe’deki çığöşü gibi harfleri kabul eder. İşte sırf burda unicode desteği gerekiyor. Ben C++ programlıyorum ve artık unicoda geçtim memnunumda. Delphiyede yakınzamanda başlama isteğim var. Bakalım hayırlısı.
February 15th, 2009 at 03:23:56
Ya ben anlamış değilim neden delphi 2009 çıktı çıkalı hep kötü yönleriyle anlatıldı bence muhteşem bi yapıdır delphi 2009 bikere hiçbir dilde olmayan refactor özelliği var bu sizce basit özellikmi delphi 2007 ye de koydular bu özelliği fakat 2009 da bu özellik iyice gelişti neden bunlardan bahsedilmiyo ayrıcı bir dilin unicode desteklemesi windows 98de çalışmıyacağı anlamını içeriyosa ben derimki çalışmasın sorun bile olmaz çünkü artık windows 98 kullanmak çok saçma çünkü kullanıcıya şu anki teknolojide yanıt vermiyo bikere windows 98 de çalışırmı çalışmazmı gibi bi düşünceyi bile aklımıza getirmememiz lazım genelde böyle söyleyenler zaten microsoft hayranlarıdır aman microsoftun çıkardığı her ürünü destek versinde ne olursa olsun diyosunuz isterseniz windows 95 de de çalışsın ne dersiniz delphi 2009 delphi 2010 da beklenen özelliklerin altyapısını hazırladı ve kullanıcıya sunda ve göreceksinizki delphi 2010 çıkınca piyasada delphi 2010 dan daha iyi bir dil olmayacak