1

Konu: global ve public değişkenkler

Selamlar,

Ben bir soru sormak istiyorum, neden global ve public değişkenlere öcü gözüyle bakıyorsunuz ? Bunu açıklama imkanı olan varmı ?

2

Re: global ve public değişkenkler

Public malum uygulama boyunca varligini surduren bir degisken , sakıncasi eger tanimli degiskeni unutupta local tanımlama yapıp kullanılması durumunda runtime error  alabilme sıkıntısı yaratir, ayrica bir tablonun alani ile ayni tanımlama yapilirsa vs ... ama deneyimli kullanicilar zaten prefix lerle calismayi ve kabul gormus gc,lc,ln,ld,ll,tn gibi prefix leri kullanmayi tercih ediyorlar .
Bunun dısında bilmedigim sakıncalari Cetin hocam daha iyi aciklayabilir.

ayrica Dökümanlar bölümünde Tarkan ın detayli bir yazisi var bu konu hakkında

http://www.fox4um.com/doku.php?id=vfp_d … r#internal

3

Re: global ve public değişkenkler

Cetin,
Biraz tarihce, biraz diger diller, prosedural-object oriented calisma isin icinde.
Eskiden isler daha kolaydi degisken yonetiminde. Programlar bir noktadan baslar, herhangi bir noktada baska bir procedure/function cagirir, o belki baskasini cagirir ama sonunda ilk cagirilan yere gere donerdi. Bunu bir kod agaci gibi dusunursen, herhangi bir anda agacin bir dalina saparsan kodun gene o sapma noktasina donecek. Ayni dallanma blogundan ayni anda calisan baska bir tane de yok.
Object oriented cikti mertlik bozuldu:) Artik herhangi bir anda ayni dal blogunun veya onun alt dallarinin kac kopyesinin calistigini bir anlamda bilmiyorsun ve senin kontrolunun disinda. Basit bir ornegi herhangi bir form. O buyuk bir obje, bircok baska objeyi icerebiliyor, metodlari vs ve ayni anda kendisinin veya onun cagirdigi formlarin N tanesi calisiyor olabilir. Baska bir benzetmeyle, multiuser zaten dertken, senin kendi tek makine, tek session uygulama ortaminda bile multiuser gibi davranan birsey var. Buraya kadar gene iyisin, sadece tek bir uygulamanin sinirlari icinde oldugumuzu var sayiyoruz. Simdi bu ortama public degisken soktugunu dusun. Adi ustunde degisken. Milisaniyeler icinde hangi objenin hangi metodu tarafindan degistireleceginin garantisi yok. Cok basit bir metod:

Visual Fox Pro
kod = 123 && veya thisform.cmbMalkod.value gibi birsey

select myTable
locate for kod = m.kod
if found()
  replace stokseviyesi with stokseviyesi + 1
endif

Simdi soru su. Bu program parcasi hangi malin stokseviyesini arttirdi (eger bulduysa - ya da 123 oldugu halde bulmama sansi var mi)? Sansin varsa 123 kodlu olan bir artti. Ancak baska bir senaryo:

Bu kod parcasi ilk satiri gectikten sonra, paralel calisan bir baska formdaki ayni veya benzer bir program:

kod = 456

dedi. Yani bu kod parcasinin bir kopyesinin sadece bir satir farkla calistigini dusun. Sonuc kotu. 123 icin hicbirsey yapilmazken, 456 nin stokseviyesi 2 artabilir bu durumda.

Baska bir sekilde aciklamak gerekirse VB kodlarini dusun (VB6'ya kadar).

txtCustomerID.Text = "Ahmet"
CustomerForm.Refresh

vs.

VFPdeki gibi objeleri ve property,methodlari varmis gibi. Ama VB6 object oriented degildi. Cok cok basit nedeni (kitap yazmiyoruz sonucta:) processing modeli prosedural, duz, tek yonlu vs.

txtCustomerID.Text dedimi o formun txtCustomerID propertysinden bahsediyor. Onun icin basinda thisform gibi bir referansa ihtiyaci yok (VB.Net, VC#.Net vs .Net de de benzer sekilde kodlar - o zaman onlar da object oriented degil gibi bir yaklasim yanlis ama cok uzun hikaye, compilerin sessizce arkada yazdigi kodlar filan var isin icinde - yani hersey gercekte gorundugu gibi gitmiyor:)

VFP kod parcasi ornegine donersek, cok hakli olarak bunun olabilecegini goster de gorelim diyebilirsin. O haliyle ve isin icine baska birsey katmadan gosteremem (ve tabii ki derdim zaman olarak yakalayamamak, tek CPU filan degil). Mesele VFP o haliyle beni koruyor. STA modeliyle calisiyoruz (Single Threaded Apartment). Yani basitce bir thread isini bitirmeden diger thread calismiyor (keske bu kadar basit olabilse). Kodda gun geldi ufak tefek degisiklik yaptin ve diyelimki araya onay almak icin messagebox() koydun. Ve hain kurt o gunu bekliyordu:) Yarattigin "wait state" nedeniyle diger threade calismak icin gun dogdu ve simdi 2 kod parcasi artik biribirinin isine karisabilir hale geldi:)

(Bu arada unutmadan ekleyeyim, hic private session kullanmadigini dusun, acik olan tablolar -tabii degil sadece hayal et- public degiskenlere benzer seyler gibi. Onlarin problemlerini hepimiz hergun yasiyoruz, dersimizi aliyoruz zaten).

VB activex yapimcilarinin, zaman zaman sayfalarnda (ki bazilari dunyaca meshur, konunun tek activex saglayicisi) sucu kendilerinde aramak yerine soyle cumleler kullaniyorlar "gorduk ki VFP'nin activexlerle calisma problemi var. Filanca metodu calistirirken autoyield = .f. yapin". Yani benim activex'im calisirken VFP'nin event processingini durdur diyor! Nedeni basit activex kendini hala prosedural kod doneminde saniyor. Problem cikan yerlerde genelde bir gecikmenin -wait state- oldugu yerler, tesaduf iste:)

Public degiskenlerin diger bir problemi, davranislari. Garip bir degiskenin ne davranisi olacak suc VFPde:) Mesela bir metoda parametre olarak 123 gonderdin, o da parametreyi "kod" adli bir degiskenle aliyor (yukaridaki kodu hatirla). Simdi bu "kod" kimin "kod"u:) Metodun mu, yoksa public olan mi? VFPnin "variable hiding" - degisken gizleme ozelligi devreye giriyor ve o procedure icin private bir "kod" var. Gercek public olanla oynanma sansini ise tamamiyle ortadan kaldirmis degil.

Tum bu problemleri saglam bir degisken isimlendirme ve benzeri yontemlerle astigini varsayalim (okyanus gecildi yani:). STA da seni koruyor - mu acaba? Benim kucuk uygulamam o kadar guzel calisiyor ve icinde hic kullanici ara yuzu filan da yok, neden bunu C# ile biraz multithread kullanmayayim. Ya da o karmasik is ben iyisi COM yapayim, web programlariyla kullanayim. IIS ve COM.dll. Multithread dunyasina hos geldiniz, o da ne, kapida "public degiskenleri olanlar giremez" yaziyor! Kim takar ben patronun buyuk ogluyum. Girdim iceri ve fistik gibi:

public gcDbPath && bu gc on ekine de gicik oluyorum ya neyse
gcPath = "c:\dataffolder\folderX"

var bende. Ya da bunu benim siteye ait registryden filan aldim. Gayet mutlu calisiyoruz. Problem yok, kapidaki gorevliyi de kovdurmayi bile dusunuyorum. Gecenin ilerleyen saatlerinde o da ne ortalik biribirine girmeye basladi. Hay ... benim ikiz kardesim de gelmis. Y sitesine takiliyor ve registryden:

gcPath = "c:\dataffolder\folderY"

yapmis!

Evet ne yazik ki public gercekten public:)

Peki oApp bu sorunu nasil cozuyor. O da public. Aslinda tam olarak cozemiyor. Sadece mudahale alanini cok daraltmis durumda. Kenid propertylerine dogrudan dokunmak yerine kendi metodlarindan isiyorsun.
? oApp.Version
yerine:
? oApp.GetVersion()
gibi. Yani bir cesit access-assign katmani. Kulfetli gorunuyor, zaten oyle de. Ama ne yazik ki guvenlik testini gecmek icin gerekli.

Anti parantez eger C#,C++ ile calisirsan public degiskeni hic kullanmasan da VFP de gereginden fazla ozgur calistigini fark ediyorsun:)

Son olarak, public degisken neden ocu benzetmesi:
Makinenin sistem hafizasinin public oldugunu dusun. Her uygulama al gulum ver gulum istedigi gibi kullaniyor, kendi adres space yerine dogrudan istedigi adrese yazip okuyor. Cok cok kaba bir benzetme ya korkun diye ekledim:)

Sonucta VFPde foxbase,foxprodan gelen, diger dillerde de oldugu gibi public var. Dokumente edilmis durumda ve programcinin gercekten ne yaptigini iyi bilmesi durumunda kullanilir da. Zaten problemleri basta gorulmuyor. Gorunce de kendine kufretmeye basliyorsun neden basta public yaptim diye. Uygulamalar da bir kez yazilip bitmiyor ki surekli buyuyup karmasiklasiyorlar. Ne yaptigini iyi bilsen bile yakalanman mumkun. Hic olmazsa tek bir oApp uzerinden dizginlemek daha kolay.

4

Re: global ve public değişkenkler

Benim bu değişkenlerle ilgili bildiğim tek şey hafızada daha fazla yer kaplaması ve tabiki ramden yemesi bunun sonucunda ise programın daha yavaş çalışması..

5

Re: global ve public değişkenkler

adaşım kusura bakma ancak teşekkür edebiliyorum uzun bir süredir site kapalı durumdaydı.


Teşekkürler,