Zafer, söylediklerinin hepsi gerçekten bütünüyle doğru ve üstelik @property'nin kullanımıyla ilgili konular ama @property'yi anlatmıyorlar.

@property, bir üye işlevin sanki işlev değil de bir üye değişkenmiş gibi kullanılmasını sağlar. Evet, sarma vardır ama @property sözcüğünün sağladığı tek olanak o işlevi parantezsiz olarak çağırabilmek.

"Sanki bir üye değişkenmiş" olabilmesi için de @property işlevlerin isimlerinin "get", "set", "getir", "ayarla", vs. gibi eylem içermemesi önemli. O zaman üye değişken gibi olmuyorlar.

Senin örneğini aşağıdaki gibi değiştirmek isterim. Önce nitelik işlevleri ile karışmasın diye üyenin isminin sonuna alt çizgi ekliyorum. Hmmm... ve değişken ve işlev isimlerinde "ütü"leri de kaldırıyorum; zaten bir ütü sınıfı içindeyiz.

Ek olarak sanırım enforce()'un mantığı ters olmuş. Yüzden fazla olmaması gerekiyor, değil mi? (Bir düzeltme daha: erişim @property işlevinin void olmaması gerekiyor.)

import std.stdio;
import std.exception;

class Ütü
{
   int sicaklik_;    // 0..100 derece

   this()
   {
       sicaklik_ = 0;
   }

   @property public int sicaklik()
   {
       return sicaklik_;
   }

   @property public void sicaklik(int yeniSicaklik)
   {
       enforce((yeniSicaklik >= 0) && (yeniSicaklik <= 100),
               "Ütü sıcaklığı bu değere ayarlanamaz.");

       sicaklik_ = yeniSicaklik;
   }
}

void main()
{
   auto ütü = new Ütü();

   /* Sanki ütü'nün 'sicaklik' isminde bir üyesi vardır. Onu
    * bir üye değişken gibi kullanabiliriz:*/
   ütü.sicaklik = 42;
   writeln(ütü.sicaklik);
}

(Not: @propert'yi denemek isteyenler dmd'yi mutlaka -property seçeneği ile kullansınlar yoksa zaten her üye işlev parantezsiz çağrılabildiği için @property'nin anlamı kalmıyor.)

Ali

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

Alıntı (Salih Dinçer):

Öyle mi? Küçücük bir örnekle gösterir misin. ;) (JSON ile ilgili olmasın ama çünkü o kod çok ilgisiz olanaklar içeriyor.)

Düşünelim:

• @property, işlevleri parantezsiz çağırabilme olanağı

• UFCS, işlevleri ilk parametrelerinin üye işleviymiş gibi çağırabilme olanağı

Ben işlev çağırma dışında ilgi kuramıyorum. :(

Ali

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

Son mesajını anlamadım. :(

Ali

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

Bence foo ve bar'a devam. Zaten yabancılar da nereden geldiğinden emin değiller. (Benim bu güne kadar rastladığım hiç bir açıklaması kesin değildi.)

Ali

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

Sabah uyandığımda dün ki mixin@property macerasından emin olmak istedim de şöyle bir sonuç elde ettim:

import std.stdio: writeln;

string yaz(T)()
{
   return `writeln("Merhaba");`;
}

void main()
{
   mixin(yaz!string()); // nasıl derlersen derle...:)
   mixin(yaz!string  ); // -property ile derlenirse hata verir
   mixin.yaz!string;    // derleme hatası vermez ama çalışmaz da...:)
   //mixin yaz!string;  // derleme hatası verir
   mixin(`writeln("Merhaba");`); // özetle yukarıdaki hariç hepsi derleniyor ama biri çalışmıyor...
   writeln("bitti, 4. nire?");
}

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

Alıntı (acehreli):

enforce() için teşekkürler, hata yapmışım daha dikkatli olmam gerekiyordu. Neyseki sen farketmiş ve düzeltmişsin ;-)

Ancak ikinci düzeltme yanlış olmuş, ben örnek kodlarımda erişim @property işlevi tanımlamamıştım.

Ben @property'nin doğası gereği dış dünyaya açık olduğu için erişim belirteçlerini kullanmıyorum ama senin yazdığın gibi örneklerde bunu açıkça yazarak bu konuyu inceleyenlere örnek olmak konusunda senin kodlamanı daha doğru buluyorum.

Ben tüm erişim belirteçlerini metot, üye değişken, @property v.s. olanaklarının en başına yazıyorum, sen @property kelimesinden sonra kullanmışsın sanırım arada bir fark yok?

Son olarak benim anladığım property konusuna bakış açımız farklı, belki ileride bir gün bu sohbeti yüz yüze devam ettiririz. :)

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

Alıntı (acehreli):

>     mixin.foo!string; (1)
>     mixin foo!string; (2)
> ```

>
Bence de, ben de şöyle denedim:

import std.stdio: write;

template foo(T)
{
T değişken = "Merhaba ";
}

void main()
{
mixin.foo!string; // noktasız da çalışyor!

   //değişken = "Merhaba ";
   write(değişken);

   değişken = "Dünya...\n";
   write(değişken);

}

**Çıktısı:**
'Merhaba Dünya...'

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

Şu notların aslında şablon katması (template mixin) kullanıyorlar:

• "derleme hatası vermez ama çalışmaz da"

• "derleme hatası verir" (aslında bir şablon ile kullanılsa derleme hatası vermez)

O söz dizimlerine uysun diye bir şablon tanımlıyorum:

import std.stdio: writeln;

template foo(T)
{
   T değişken;
}

void main()
{
   {
       mixin.foo!string;
       değişken = "merhaba";
       writeln(değişken);
   }

   {
       mixin foo!string;
       değişken = "dünya";
       writeln(değişken);
   }
}

Yukarıdaki iki bloktaki mixin'ler tek satırlık kod katıyorlar: 'değişken' isminde bir değişken tanımı. Aynı isimde iki değişken karışıklık yaratması diye farklı kapsamlarda tanımlamak zorunda kaldım.

Çıktısı:

'merhaba
dünya
'

Ali

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

Söylemeyi unuttum... Aşağıdaki iki yazım birbirinin eşdeğeri oluyor:

   mixin.foo!string; (1)
   mixin foo!string; (2)

Birinci satırda mixin'den sonra boşluk olmasının gerekmemesi şaşırtıyor ama aslında birinci satır şunun eşdeğeri:

   mixin .foo!string; (1)

foo da "modül isim alanında tanımlanmış olan foo" anlamına geldiği için bu kodda ikincisinin eşdeğeri oluyor.

Ali

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

Alıntı (acehreli):

struct Fibonacci { ... }

void main {
   :    :    :
   Fibonacci.take(100).cycle.writeln;
}

Ama o gün gelirse ki (parametreyi kullanırsak) şimdi de öyle her nesne sağına parantezler ile uğraşıyoruz. Bu böyle olmamalı ve yazılımcı bunlar ile vakit kaybetmemeli. Gerçi Fibonacci(). ile başlayıp devam etme şartı var ama sanırım bu (new ile) yeni bir nesne oluşturularak aşılabilir.

Neyse anlayış farklılıklarımız var ama bence ECMA diye bir standart varken bütün diller ona doğru kayması hoş olurdu...

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