Alıntı:

Bir "Yeni başlayan" olarak söyleyeyim; Yukarıdaki yeterince açık bir ifade. Burada Can'ın a ifade ettiği gibi kendi algoritmamıza göre kendi tercihlerimizi yapacağız ve zaman içerisinde bu seçimler oturacak. Şu ifade çok daha aydınlatıcı görünüyor
Alıntı:

Bolca pratik yapmak demek; Katılıyorum.
Alıntı:

Acemilik kaygıyı da beraberinde getiriyor. Bu tür yanılgılara düşmek de öğrenmenin bir parçası aslında. Yapı ve sınıflar yeniden çalışılacak demektir bu ki çalışılmakta hAlA.
Alıntı:

Yanıtla beraber makale değerinde bir açıklama da almış oldum: Teşekkürler.

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

Alıntı (erdem:1305370083):

Digital Mars'taki açıklamalar açık değil. :p Orada listelenen maddelerin ve ile bağlanmaları gerektiğini düşünüyorum:

Alıntı (D spec):

* are allocated as local symbols in a function
* are allocated using new
* use new with no arguments (constructor arguments are allowed)
* have the scope storage class

Yani; yerel olmalı, new ile ayrılmış olmalı, new'ün parametre almayanı çağrılmış olmalı, ve scope depolama türünden olmalı... diyecektim ki bunula ilgili bir hata aradım ve buldum:

http://d.puremagic.com/issues/show_bug.cgi?id=1521

Neredeyse 4 senelik hatada aynen benim söylediğim sorgulanmış: O sayfadaki maddeler ve ile mi bağlanıyorlar, veya ile mi?

Bence bu konuyu şu anlayışla geride bırakalım: Sınıf nesnesi öbekte oluşturulur; sınıf değişkeni ise tanımlandığı duruma göre değişir. Bunun benzerini çok yazdık ve gördük ama bir programcık daha:

import std.stdio;

struct Yapı
{
   int i;
}

class Sınıf
{
   int i;
}

scope class scope_Sınıfı
{
   int i;
}

void main()
{
   auto y0 = Yapı();
   auto y1 = new Yapı;

   auto s0 = new Sınıf;
   scope s1 = new Sınıf;

   // auto s2 = new scope_Sınıfı;  // derleme hatası
   scope s3 = new scope_Sınıfı;

   bilgiVer("normal yapı",            &y0.i);
   bilgiVer("new ile yapı",           &y1.i);
   bilgiVer("normal sınıf",           &s0.i);
   bilgiVer("normal sınıf scope ile", &s1.i);
   bilgiVer("scope sınıfı scope ile", &s3.i);
}

void bilgiVer(T)(dstring açıklama, T adres)
{
   writefln("%30s: %s", açıklama, adres);
}

Çıktısından anlaşıldığı gibi, yapı ve sınıf nesneleri yığıtta da öbekte de oluşturulabiliyorlar:

' normal yapı: FFEA7A68
new ile yapı: F7372E20
normal sınıf: F7372E18
normal sınıf scope ile: FFEA7A7C
scope sınıfı scope ile: FFEA7A8C
'

Alıntı:

Ters düşüyor. O sayfadaki açıklama hatalı.

Alıntı:

Orada "instance" ile "object" aynı anlamda kullanılmış.

Alıntı:

> > class A
> > {
> >     int x = 42;
> > }
> >
> > unittest
> > {
> >     auto a1 = new A;
> >     assert(a1.x == 42);
> >     auto a2 = a1;       // yeni bir A nesnesi oluşturulmaz sadece A nesnesi
> >                         // a2 tarafından da gösterilmeye başlanır
> > // ...
> > }
> > ```

> >
>
> Benim değiştirdiğim kısım şu şekildeydi:
>
> 'Sınıflar kişiliği olan elemanlar oldukları için kopyalanmamaları gerekir.'

Öyle çok kısıtlayıcı oluyor. Duruma göre nesneleri özellikle kopyalamak zorunda kalabiliriz. Hatta kopyalamazsak hatalı olabilir. Bunun benzerini dizilerde görebiliriz: Referans türleri oldukları halde .dup ile kopyalayabiliyoruz ve duruma göre kopyalamamız gerekiyor.

Alıntı:
> 'Yukarıdaki örnekte olduğu gibi. Kopyalanmamaları gerekiyor derken aynı nesneyi gösteren birden fazla referans olmasına izin vermemeliyiz.'

Ama o zaman nesnelerin kişilikli olmalarına ters düşmüş oluruz. Duruma göre tam tersi olarak birden fazla referansın aynı nesneyi göstermesini isteriz. Örneğin bir çatı, o çatıyı kullanan kodların oluşturduğu bir sınıf değişkenini (referansını) alabilir ve ileride etkileşmek için saklayabilir. Nesneyi oluşturan kodlar da aynı nedenle saklayabilirler.

Sonuçta aynı nesneye erişim sağlayan değişken (referans) hem çatının içindeki bir dizide duruyor olabilir, hem de onu oluşturan tarafta örneğin bir eşleme tablosunda... Çok doğal bir durum. (Şimdilerde kullandığımız bir C++ çatısında aynen böyle oluyor.)

Alıntı:
> 'Çünkü beklenmeyen  bir şekilde referans değiştiği zaman uygulamanın bir yerinde olan sürpriz değişiklikler diğer tarafına da yansıyabilir.'

Kabul ama o zaman programda bir hata var demektir. Eğer bir tarafındaki değişikliklerin öteki tarafı etkilemesini istemiyorsak .dup ile kopyalamış olmalıyızdır.

Ali

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

Alıntı (mert):

Başka yolu yok galiba. Ancak deneye yanıla öğrenebiliyoruz. :)

Alıntı:

Çok doğru! Acemiyken, yazılmış olan cümlelerden hangisinin ne kadar önemli olduğu bile anlaşılamıyor. Bir çok cümle, kavram, "yapın" öğüdü, "yapmayın" öğüdü, teknik bilgi, şaka, vs. :) Bazen aslında önemsiz olan bir bölümü, bildiklerimize uydu diye anladığımız için diğerlerinden daha üstte tutuyoruz.

Son olarak, yapı-sınıf seçimi konusunda çok kaba bir ilke: Öncelikle yapı düşünün; yetersiz kalırsa veya dertli olmaya başlarsa sınıf olmalıymış demektir.

Yapı olarak tanımlarsanız ve o türün çeşitleri olacaksa, örneğin çeşitli hayvanları ifade edecekse, o zaman C'de çok uygulandığı gibi bir enum'dan yardım almanız gerekir. Nesne yönelimli programlamanın farkını gösteren klasik örnek:

enum HayvanÇeşidi { kedi, köpek, at }

struct Hayvan
{
   HayvanÇeşidi çeşit;

   void şarkıSöyle()
   {
       final switch (çeşit) {
       case HayvanÇeşidi.kedi:
           writeln("miyav");
           break;

       case HayvanÇeşidi.köpek:
           writeln("hav");
           break;

       case HayvanÇeşidi.at:
           writeln("iii");
           break;
       }
   }
}

Yukarıda görüldüğü gibi yapı da olur. Ama Hayvan daha karmaşık olmaya başladıkça, örneğin üye işlevlerin sayısı arttıkça o yöntem daha dertli hale gelir. Onun için belki de baştan sınıf olmalıymıştır (güzel Türkçemiz! :-p):

Aslında karşıt ilke de olur: öncelik her şeyi sınıf olarak düşünün, uygunsuz kaçmaya başlarsa yapı olarak değiştirirsiniz.

Belki daha güzel bir ilke: çeşidine göre farklı davranacak olan üye işlevi varsa sınıf olsun. Örneğin eğer yalnızca dikdörtgenlerle ilgileniyorsak ve bu dikdörtgenlerin yalnızca renk, en, boy, vs. gibi nitelikleri farklıysa; çizilmeleri, alan hesapları, vs. hep aynıdır. O zaman Dikdörtgen türünü yapı olarak tasarlamak uygundur. Ama farklı şekiller varsa, örneğin alan hesapları farklı olacağından onları sınıf yapmak uygundur.

(Zaten çok söylenmiş olan şeyleri tekrarladım. :))

Ali

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