[Gelistirici] programming.libs nedir?

[Barış Metin]

Salı 14 Mart 2006 19:40 tarihinde, Eray Ozkural şunları yazmıştı: 
> Her kutuphane programcilar icin yazilmistir, ama sonra yazdiklarima
> bakarsan programming.libs icin ayri kriterler soyluyorum. *Biz* neden
> koyuyoruz bu paketi
> sisteme? Programcilar icin mi, yoksa bagimlilik saglamak icin mi? Ikinci
> tur olanlarini
> ozellikle bagimliligini saglamak icin bulunan paketin yanina ilistirmistim.

Bizim paketi neden koyduğumuz gerçekten önemli mi? Bence hiç önemli değil. 
Bizim anlık ihtiyacımıza göre şekillendirmek mantıklı değil bileşenleri. 

Aslında (yanlış hatırlamıyorsam Gürer bunun gibi bir şey söylemişti) paketleri 
gruplamanın ideal yöntemi ağaç değil bir graph sanırım. Bu yüzden bileşen ve 
kategorileri birlikte kullanarak bir yalnızca algıya yönelik bir graph yapısı 
oluşturabiliriz sanırım. Bileşen ve kategorilerin amaçları farklı, bunu 
unutmuş değilim.

İkinci bir "aslında"; her paketi bir bileşene uydurmaya çalışmak bizi 
zorluyor. Bu zorlama her durumda işe yaramıyor. İncelediğimiz gördüğümüz 
hatta oluşturmaya çalıştığımız tüm yapılarda bileşenler ve kategoriler iç içe 
girmek zorunda kalıyor. Ya bunu kabul edeceğiz ya başka bir çözüm bulacağız. 
Bunu kabul etmekte ciddi bir sıkıntı görmüyorum şu anda.

> Daha sonra da soyledigim gibi (eger gerisini okursan) top-level bir

Hepsini okudum tabi. Fakat en temelde söylediğin fikirde hata olduğunu 
düşündüğüm için geri kalanına başa referans vererek tekrar tekrar aynı şeyi 
söylemek istemedim. Normali bu sanırım. Yine de bu mesaj için senin istediğin 
gibi yapayım. Ayrı ayrı yazayım...

> component'a
> koyulmalari daha dogru olur "libraries" gibi programming.libs'den ziyade.
>
> Cunku header dosyalarindan ibaret degil kutuphane paketleri, bizim icin
> asil onemli
> olan sey cogu zaman link edilen shared objectler....

Bunu nasıl ayıracağız peki? Yukarıda söylediğin gibi "biz paketi niye ekledik" 
sorusunu sormak mantıklı değil. Biz bir paketin bağımlılığı olarak eklemiş 
olabiliriz. Bu durumda onun yanına koyarız kütüphaneyi. Sonra başka bir paket 
daha buna bağımlı olur, diğerinin yanına taşıyamayacağımız için mantıksız bir 
görünüm olur. Bu yüzden kütüphanelere özel davranıp bir yerde tutmak 
mantıklı. Kütüphanelerin programcı ihtiyaçları olduğunu düşünmek de mantıklı 
bence.

> Ayrica bir "library" diye category'miz var, neden?

Bileşenler ile kategorilerin çakışmayacağını düşünmek, soruna fazla idealist 
yaklaşmak demek bence. Çakışacaklarını biliyoruz zaten, daha önce 
applications örneğini vermiştim. Yine dün konuştuğumuz bir şey; aslında 
sonunda "s" olan şeylerin (shells, languages, libs, games, emulators) bileşen 
değil kategori olması gerekiyor. Bunun PiSi belgesindeki bileşen ve kategori 
tanımlarımızdan dolayı açık olduğunu düşünüyorum.

> Butun library'ler ayri bir component altina gitmeli diye birsey yok,
> aslinda bu
> yanlis bile, cunku library'ler sadece UI'i olmayan programlar....
>
> Ideal olarak her paket bir alt-sistem belirtmeli, bir alt sistem de,
> kitapliklar, cli
> ve gui app'leri, daemonlar vs. icerebilir.

Her paketin bir alt-sistem belirtmesini anlayamadım. Her "bileşen" demek 
istedin sanırım. Doğru, fakat dediğin gibi ideal olarak...

> applications.multimedia ornegin tam olarak boyle bir yer.

applications öyle bir şey değil. applications kendi başına bir alt-sistem 
belirtmiyor. applications aslında bir kategori, bu açık değil mi? Bileşen 
zorlamamız yüzünden şu anda applications diye bir bileşen var.

> multimedia islevi saglayan ve ayni component'daki paketler tarafindan
> kullanilan
> ivir zivir paketlerin yeri burasidir bence.

"multimedia işlevi" dediğin zaman aynı işlevi sağlayan birden fazla paketin 
olacağını da düşünmek gerekiyor. Zaten işlevine göre ayırdığımız "şey" 
bileşen değil kategori. Yaptığımız tanım bu en azından (ki bence doğru).

http://www.pardus.org.tr/projeler/pisi/pisi/node_13.html

> Bir daha soyleyeyim, programming.libs butun kutuphanelerin koyulacagi
> bir yer
> degil.

Yukarıda yazdığım nedenlerden dolayı, katılmıyorum.

iyi çalışmalar,
-- 
Barış Metin
-------------- sonraki bölüm --------------
A non-text attachment was scrubbed...
Name: kullanılamıyor
Type: application/pgp-signature
Size: 189 bytes
Desc: kullanılamıyor
URL: <http://liste.pardus.org.tr/gelistirici/attachments/20060314/6b983f4b/attachment-0002.pgp>