Alıntı (canalpay):

>         this.boy = boy;eskiEn = to!(immutable int)(en);eskiBoy = to!(immutable int)(boy);
> ```


eskiEn en'den kopyalandığı için orada tür dönüşümüne gerek yoktur:

   this.boy = boy;
   eskiEn = en;
   eskiBoy = boy;

Ali

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

Kaç tane old değişkeni tutmalıyız? Bir adet olsa, ötele() dolaylı veya dolaysız olarak bir kere daha çağrılsa ortalık mahvolur:

   void ötele(int yukarı, int sağa)
   // ...
   body
   {
       //old.en = 0;
       solÜst.satır += yukarı;
       solÜst.sütun += sağa;

       // Ekliyorum:
       başkaNokta.ötele(100, 200);  // <-- bu çağrı, az önce kaydettiğimiz old'un
                                    //     üstüne yazılmasına neden olur.
   }

Böyle genel amaçla kullanılan tek (veya bir kaç adet) değişken olduğunda işlevler non-reentrant hale gelirler. Hiç istenmeyen bir durumdur. :(

Ali

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

Alıntı (acehreli):

• Şimdi bir yapımız var (DörtgenBölge) ve bu yapı içinde komşusu başka bir yapı (Nokta) temsil ediliyor.
• Tüm yapıların elemanları Public ve dışarıda, tanımlandığı yerde (bölge) değerler değiştirilebilir.
• Ama Nokta, DörtgenBölge'nin elemanı yani başka bir yapıya bağlanmış, nested değil...
• Ayrıca 'ötele()' isminde bir işlevimiz var ve dörtgenin sol üst köşesindeki noktayı sağa ve yukarı alıyor.

(**Ara Not: **Gerçi Ali hocam bu örneğin farklı şekilde yapılabileceğini ve bu haliyle tahammül sabrı göstermemiz gerektiğini belirtmiş. Yine de küçük bir mantık hatası var gibi. Yani ötelenen dörtgeni en/boy (sağ alt köşedeki nokta değil mi?) değerlerini de aynı oranda arttırarak işlem yapmalıyız. Yoksa dörtgenin sınırları sol üst köşeden küçülür/büyür ve sanki bu noktadan boyutu değiştirilen bir resim gibi olur. Belki de ben yanlış anlıyorum ama öteleme dediğimiz resmin iç kısmından tutup taşımak olarak algılıyorum.)

• Biz istiyoruz ki öteleme sırasında başka bir işlevde (alttaki maddedeki gibi bir durumda) en/boy oranı değiştirilmesin.
• Tabi ilk iletideki şekliyle çok basit ama biz bunu çok karmaşık bir programın parçası olduğunu düşünelim.

Bu analiz sonunda private yapıldığında sanki in/out kümesine ihtiyaç yok gibi duruyor. Bilmem ki başka bir örnek üzerinden mi gitsek? Peki şöyle bir soru sorsak: Başka bir işleve girilirken ve çıkılırken yapılacak bir işlemlerde (in/out'dan bahsediyorum) birbirlerinden haberdar olması gereken başka bir durum var mı?

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

Alıntı (Salih Dinçer):

Ama 'out' blokları işlevin kendi denetimi içindir. Üyeler private da olsa, başka işlevler karışmasa da işe yararlar.

Alıntı:

Eğer Andrei'nin önerisini söylüyorsan, evet. Ama buradaki 'eskisi' gibi global değişkenli çözümler kırılgandırlar çünkü ancak bir işlev çağrısının durumunu saklayabilirler.

Ali

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

Alıntı (acehreli):

Biz teknik olarak in kümesine ihtiyacımız olmadığına (in yerine body girişini kullanabildiğimize) göre, bu şekilde nested (içiçe) yapı gerektiğinde kullanılabilir. Öyle ya, sonuçta bunlar release olduğunda kaybolan olanaklar.

Bence in/out kümelerinin birbirine her türlü şekilde (in'nin ayrı bir küme olması; out'un ise işleyiş sırasından dolayı komşularına etkisi olmaması) yalıtımda olması gerekiyor. Çünkü onları tek taraflı da olsa dış dünyadan bağımsız (yan etkisiz) çalışması daha doğru olsa gerek. Zaten biz bunları, assert'leri bir düzene sokmak için kullanmıyor muyuz?

Elbette assert'ün, programı sonlandırması yan etki değil, olsa olsa doğrudan bir etki. Öyleyse tıpkı unittest'ler (tüm modülü test eden kümeler) gibi in/out kümelerini akan veriyi işlevin kendisini test etmek için kullanmalıyız. Belki tek farkı, bunları çalıştırmak için ek bir parametreye ihtiyaç duymamamız...

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

Hayır, en/boy sağ alt köşe değil: dörtgenin eni ve boyu.

Tamam, üyeleri private yapalım. Türün bir üye işlevini çağırıyoruz ve bu işlevden çıkarken belirli bir koşulun bozulmamasını istiyoruz: İşleve girildiğinde falanca üyenin değeri ne ise, işlevden çıkıldığında da o olsun. Yani işlevin davranışını denetlediğimiz için bunun private ile bir ilgisi yok çünkü bu işlev belki bir yanlışlık sonucunda üyeyi değiştirebilir.

Her ne kadar en doğal yer olarak görünse de bunu 'out' bloğunda denetleyemiyoruz.

Ali

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