Alıntı (acehreli):

Haklısın hocam, birim testleri için dediğin gibi şart. Üstelik doğru yoldan sapmamak için böyle küçük parçalar gerekli...

Alıntı (acehreli):

Belki de balık hafızalı olduğumdandır. Açıkçası ilk defa kodu gördüğümde n'oluyor, ne bitiyor? Kim kimden ne alıyor, nereden ne çıkıyor aklım almıyordu. Tabi günün yorgunluğunun da etkisi vardı ama sanki benim yaptığım gibi daha anlaşılır.

İtiraf etmeliyim; başta sandım ki ben bunu bir haftada çözemem...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Peki hocam mixin olayı neden bir önceki sürüm olan DMD 2.058'de derlenemez? Hatırlatmak için hatayı alıntılayım:
Alıntı:

İşin ilginci yapı kaç defa çağrıldıysa o kadar hata tekrar ediyor. Ayrıca @property'nin espirisi nedir? Çünkü onsuz da derleniyor.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (zafer):

Bazı değerler desteklenmediği için (örneğin ulong.max) hata atılmasını istiyoruz. O assert, gerçekten de hata atıldığından emin olmak için var. Programı sonlandırmak gibi bir derdimiz de olmadığı için "bu değere karşılık hata atıldı; güzel" deyip devam ediyoruz.

Alıntı:

Olabilir ama ben "bu kapsamdan çıkılırken şu olsun" demek yerine, "şu işlem sırasında hata atılsın" demek istedim.

Not: Bu olanak bazı birim testi kütüphanelerinde (örneğin Unittest++) örneğin CHECK_THROW adı altında zaten vardır. Yapmak istediğim aslında şu kadar basitti ama D'de standart bir birim testi modülü yok:

   buİşlemSırasındaHataAtılmışOlmalı(to!JSONValue(ulong.max));

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Bu parametreleri (ayrıca -X'i) biliyorum, en azından bildiğimi sanıyormuşum. Çünkü -property'i yapı üyeleri içinde at @ ile birlikte kullanmak dışında bugüne kadar hiç kullanmamıştım. Hocam sayende her geçen gün yeni şeyler öğreniyoruz. Bunun neticesinde D camiasına ve dolayısıyla açık kaynağa adayabileceğimiz büyük bir proje çıkmaz ise ayıp bize vallahi...:)

Gerçi en büyük proje yazdığın kitap olmalı ki hocam sırasını çoktan saldı. Bu vesileyle Zafer'e de teklif etmek isterim: std.json ile alakalı dersi artık hep birlikte yazalım mı? Kapsamlı olabileceği içi ikiye, hatta üçe (Ali hocam da bu bölümü anlatır) bölmek de iş yükünü hafifletir. Zaten Zafer'in sitede yer alan bir makale denemesi var ki JSON olayını Kelimatik projesinde zat-ı muhterem başlatmıştır:

Alıntı (JSON'a başlangıç):

Ben de bir iki paragraf ile makaleye bir başlangıç yapayım ve böylece en kolay kısmını kapayım! Çok mu akıllıyım...:)

JSON (JavaScript Object Notation), Türkçe'de "ceysın" olarak okunur, (Değil mi Ali hocam?) ve çok basit bir işaret diline(Fransızca notation) sahiptir. Amaç, insanların da kolaylıkla okuyabileceği ve fazla yer kaplamayan (ama JavaScript ile uyumlu!) bir veri değişimi meydana getirmekti. Öncüsü ise bu işin tek üstadı olan Douglas Crockford (<www.crockford.com>)'dur. Öğrenince anlaşılması basit olsa da başlangıçta anlamsız gelebilir. Bu yüzden ne olmadığını tarif ederek devam edelim:

Anlam olarak, kesinlikle ne Java dili ile ne de diğer programlama dilleriyle ilgili bir şey değildi(r). Doğrudan JS (JavaScript) ile ilgili olduğu ve Java dilinin JS'ye isim olarak benzese de tarihsel açıdan (-bknz Mozilla (<www.mozilla.org>)) alakalı olmadığını önemle belirtmeliyiz. Ancak sonradan Java dahil bir çok dil ve script'de (örn. D ve AS gibi, tam liste için tıklayın (<www.json.com>)) ayrıştırıcıları (parser) yazılmıştır. Bu da çok kolay yaygınlaşmasını sağlamıştır. D'de ise, dilin içinde yatan büyük potansiyel sayesinde kullanımı inanılmaz derecede kolaylaştırılmıştır.

Sevgiler, saygılar...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (zafer):

+1

Alıntı:

JSONBelgesi() aslında std.json tarafından sunulmalı (tabii İngilizce olarak :)). JSON belgelerinin en dış elemanının OBJECT türünde olduğunu bilmemiz gerekmemeli.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Kod çok nadiren oturur. Sürekli olarak hatalar bulunur ve giderilir, hızlandırma yolları farkedilir, ek olanaklar gelir, vs.

Alıntı:

Öyle düşünürsek birim testlerini de bir noktadan sonra kaldırmalı mıyız? Ama anlıyorum tabii: Dıştaki işlev denenince iç işlemler de denenmiş oluyorlar diyorsun. Peki sen neden birleştirmekten yanasın? Öyle daha kolay mı anlaşılıyor? Çünkü bana tam tersi oluyor. :)

Alıntı:

Mahsuru yok. Benim asıl amacım alt parçaları unittest'ler içinde gösterebilmekti. mixin()'li kodlar çok karmaşık olabiliyorlar.

Aslında eklemeİfadesi() işlevini bir noktada bir iç işlev yapmayı denedim; çünkü nasıl olsa yalnızca eklemeİfadeleri() tarafından kullanılıyordu ve dışarıda durmasına gerek yoktu. Ama ne yazık ki onun unittest bloğunu içeriye alamadım.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (zafer):

Yani şöyle diyorsun:

   bool hataAtıldı_mı = false;
   {
       scope(failure) hataAtıldı_mı = true;
       to!JSONValue(ulong.max);
   }
   assert(hataAtıldı_mı, "ulong.max için hata atılmadı!");

Aslında daha temiz görünüyor ama ne yazık ki bu sefer de atılmasını umduğumuz hata yüzünden program sonlanıyor. try-catch yönteminde ise hatayı yakalayıp gözardı etmiş oluyoruz. Amaçlardan birisi de o: hata atılsın ama testlerimiz de devam etsinler.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (Salih Dinçer):

Sana özelden yazdığımı buraya da kopyalayayım:

Alıntı (acehreli):

(Sözüm meclisten dışarı ;): Lütfen teknik konuları forumda konuşalım.)

Alıntı:

dmd'yi her zaman için -property seçeneği ile kullanmanı öneririm. Aslında onun varsayılan bir seçenek olması gerekirmiş ama eski kodları bozmamak için öyle yapmamışlar.

Bence şunları hep kullanmalıyız: -unittest -w -wi -property

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (acehreli):

Sen böyle yazınca JSONBelgesi() kafamda daha da netleşti. Haklısın Ali aslında önemli olan bu bakış açısına sahip olabilmek, sanırım ustalık bu bakış açısına yaklaşabilmekle alakalı bir durum. Bende senin tecrübelerinden faydalanarak bu açıya yaklaşmaya çalışıyorum.

Alıntı (acehreli):

bool hataAtıldı_mı = false;
{
    scope(failure) hataAtıldı_mı = true;
    to!JSONValue(ulong.max);
}
assert(hataAtıldı_mı, "ulong.max için hata atılmadı!");

Hakılısın şimdi bende denedim. Scope hatayı yakalayıp yönetme şansı vermiyor. Anladığım kadarıyla scope hatanın atılmasını engellemiyor sadece bize program akışı sonlanmadan önce son bir imkan sunuyor. Bir nevi köprüden önceki son çıkış gibi sanırım.

Ancak gerçekten çok daha temiz bir kodlama sunuyor :)

Alıntı (Salih Dinçer):

Genel olarak Salih'in düşüncelerine katılıyorum ve yazdıklarınıda doğru buluyorum. Bununla beraber JSON için bir ders yazmak yerine bu konuya özel bir makale yazılmasının daha doğru olduğu düşüncesindeyim. Böylece hem makale bölümü zenginleşecek hemde bizlerin çalışmaları daha somut bir hale gelecektir. Neticede forumda konuşulanlar konular içinde atıl bir şekilde kalıyor.

Birlikte bir ders veya makale yazmak bence gerçekten zor olacaktır. Ancak bunun yerine örneğin Salih sen bu konuda bir makale hazırla ve sitede yayınlayalım, sonrasında eksik gördüğüm kısımları tamamlayacak bir makalede ben eklerim. Bence bu çok daha kolay ve hızlı olur. Aksi taktirde hepimizin tek bir makale üzerinde çalışması bence hem zor olur hemde yazı bizlerin kişisel yaklaşımları doğrultusunda şekilleneceği için bir bütünlük arz etmeyebilir.

Diğer taraftan benimde uzun süredir aklımda bir JSON makalesi var ancak bu konuyu biraz daha irdeleyip doyurucu bir makale hazırlamak niyetindeyim. Ayrıca AyarYönetici sınıfı ile JSON üzerinde bir uygulama yaparak pratikteki bazı aksaklıklarıda gördükten sonra böyle bir yazı hazırlamayı düşünüyorum ve tabi şu sınavları ve semineri bitirdikten sonra ancak bu tür işlere vakit ayırabileceğim. :)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Nitelikler başlığı (http://ddili.org/forum/thread/827)ndan aklıma geldiği için, UCFS'yi deneyim dedim de bir terslik var bu işte...:)

Çünkü 'opCastJSONValue(T)()' işlevinin sağından itibaren devam etmem (öyle ya, parantez içinde kalıyor) gerekirken soluna koyduğumda hata vermiyor. Sanki 'mixin()' özelliği parantez içine giriyor. Hadi benim bildiğim ters, peki 'writeln()' de mi ters?

@property string opCastJSONValue(T)()
{
   :    :    :
}
struct Öğrenci
{
   string isim;
   ulong numara;
   uint[string] notlar;
   // Katma (mixin) ifadeleri, derleme anında buraya gelecek...
   //mixin.opCastJSONValue!Öğrenci;          /*<-- niiiiiiiiiiiiyeeeeeeee ters...:)
   opCastJSONValue!Öğrenci.mixin;
   opCastJSONValue!(Öğrenci).mixin; //*/
}//*/
void main()
{
   :    :    :
   toJSON(&belge).writeln;
}

Hatası:
'salih@salih-NB:~/d.ders/JSON$ d.sh jsonYaz
jsonYaz.d(96): identifier expected following '.' instead of 'mixin'
jsonYaz.d(96): no identifier for declarator opCastJSONValue!(Öğrenci)
jsonYaz.d(96): semicolon expected, not 'mixin'
jsonYaz.d(96): identifier expected, not ;
jsonYaz.d(97): ';' expected after mixin
jsonYaz.d(97): Declaration expected, not '('
'
Aslında tersinde (ilgili satırın açıklamasını kaldırınca, altındaki iki satır kapandığında) hata vermiyor ve çalışıyor! Her zaman ki gibi @property'nin hiç bir etkisi de yok. Ne iş?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]