>>>>> "ES" == Emre Sevinc <[EMAIL PROTECTED]> writes:
[...]
ES> - Encapsulation yok mu yani simdi bu CLOS'ta? Java yazarken
ES> bir dosya aciyor icine class yaziyoruz, her bir sey, metodlar
ES> filan da dahil olmak üzere o dosyanin icine yazilan class'in
ES> icine yaziliyor.
Ecapsulation'in senin soyledigin manasinin yaninda bir de ic duzeni
saklamak filan gibi bir manasi var. Ikisini de dusunelim biraz simdi:
-- Multimethod imkani olan bir dilde, hangi metod hangi dosyaya
girecek?
-- Eger saklama arzusu mevzu bahis ise, bunu yapmak kabil bir dereceye
kadar. Paket sistemi kullanilabilir. Sistemin bunu zorlamasini
saglamak ise diger alisilagelmis dillere gore daha zor. Belirlenen
protokolun disina cikmayi sistem engellemiyor, kapsulun duvari
akilla cekiyorsun sistem cekmiyor. Bir de komiklik geceyim CLL'in
eskilerinden Erik Naggum'dan:
"... it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody. the practical result is
that thieves and bums use C++ and nice people use CLOS."
CLL'de bol bol konusulur bu, ilgiliysen bir google'la.
ES> CLOS'ta sanki böyle class'lar bir yerde,
ES> metodlar baska bir yerde, daginik ve pek-encapsulated-degil
ES> gibi.
Daginik olmasi mumkun ile daginik olmasi gerekli arasinda buyuk bir
yelpaze var. Dier taraftan dosya duzeni programcinin elinde, sistemin
dayatmasi yok.
ES> - OOP'nin tarihi hakikaten o kadar geriye gidiyor mu
O kadar ne kadar? Kafadan soyluyorum ilk Simula 60larin basi olsa
gerek.
ES> - Metaobject protocol baglaminda: Yani simdi ortada bir sürü
ES> nesne varken ben gidip bunlarin siniflarini degistirebilir,
ES> bambaska bir sey yapabilir, misal 2 slot varken bir tanesini
ES> iptal edebilir miyim?
Evet.
ES> O zaman o siniftan üretilmis o nesneler
ES> sacmalamaz mi? Veri kaybi olmaz mi? Bir koruma ve uyari
ES> mekanizmasi yok mu?
Sisteme bagli olarak bazi durumlarda uyari olabilir ama engelleme yok.
Slotlar kaybolabilir, bir koruma yok. REPL'de bu dene bunu.
ES> - Shared slot, Java'daki static class variable gibi bir sey
ES> mi, tüm nesnelerin paylastigi degisken filan?
Evet. O slot'a atamayi instance'lar ustunden yapiyorsun (initform
varsa instance uzerinden calisiyor). Instance olmadan atama yapmak
icin MOP kullanman lazim. Yani Java'daki gibi class-ismi.static-slot-ismi
diye ulasamiyorsun ortada instance yoksa. (Benim Java bildigimi varsayma
yanlis soyluyor olabilirim).
ES> - Continuation'lari Java'da uygulamak mümkün mü? (Bu CBC
ES> tarafindan sorulmustu, tam olarak ne ile ilgili sorulmustu
ES> simdi hatirlamiyorum).
Bilmiyorum bunu. Continuation'i dikkatli tarif etmek lazim. 'Full'
continuation uretmek CL'de de zor. Bir suru komplikasyon cikiyor.
Manasi da belli olmuyor: unwind-protect'in korudugu bir bolumun dinamik
olarak altinda kalan (dynamic contour'unda) bir yerde continuation kapip
saklarsan ne oluyor mesela? (bu klasik ornektir). Diger taraftan iyice
sulandirirsan C'deki setjmp/longjmp da continuation olarak dusunulebilir.
Google'a "upward continuation", "downward continuation" filan yedir
istersen.
Graham'in On Lisp'inde CL'de kisitli bir call/cc ornegi olmasi lazim.
Bu konuya iyice hakim olmanin bir yolu Scheme ile o tarzda bol bol
program yazmak veya en azindan okumak. SICP'de yok bu yanlis
hatirlamiyorsam. Hangi kitap iyi anlatiyor da bilmiyorum. Ciddi
schemeciler balki bir kaynak verirler?
ES> - Neden first, second, third, ..., tenth var da eleventh,
ES> twelfth yok? Neden bu kadar cok (ya da az) var? Yani nth ya da
ES> elt gibi genel olarak erismemizi saglayan bir seyler varken
ES> seventh, ninth filan neden koymuslar, bir mantigi var mi?
ES> (Bunun kücük sayilar yasasi ile bir ilgisi olabilir mi? [1])[...]
Bunu KMP'ye yahut CLL'e sormak lazim. Bir de eskilerin bunlari
kullanma konusunda 'iyi ornek olayim' diye bazen kivirttiklarini
dusunuyorum ben. Insanlar 'efendim cons cell olarak dusununce
car/cdr, liste gibi dusununce first/rest kullaniriz' filan da diyorlar
ama ben pek inanmiyorum:
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/45c9ada03f2fbc3c/e7caa0cce9b4f52d#e7caa0cce9b4f52d
BM
_______________________________________________
cs-lisp mailing list
[email protected]
http://church.cs.bilgi.edu.tr/lcg
http://cs.bilgi.edu.tr/mailman/listinfo/cs-lisp
