Alıntı (zafer):

Haklısın; kafam karışıkmış: ÜtüyüAyarlananSıcaklığaGetir()'i niteliği oluşturan işlevlerden birisi sanmışım. O andaki anlayışıma göre ÜtüSıcaklığıAyarla() değerini değiştiriyor sanmışım ÜtüyüAyarlananSıcaklığaGetir()'i de o değeri döndürüyor sanmışım.

Alıntı:

Aslında ben public'leri sen kodunda öyle yazdın diye eklemiştim. Ben C++'takine alışmışım; erişim bölgeleri gözüme biraz daha iyi görünüyor:

class S
{
private:
   // ...
public:
   // ...
}

Alıntı:

Onu da yanlışlıkla öyle yazmışım. Aslında dönüş türü dışındakileri parametre listesinden sonra yazmayı seviyorum:

struct S
{
// ...
   const(int)[] değerler() const @property
   {
       // ...
   }
}

Hatta pure, @safe, vs. de sona gelir. (Yakında pure üzerine bir makaleyi Türkçeleştireceğim.)

Alıntı:

Tabii ki! :) Seni doğru anlıyorsam sen sarmayı ön plana çıkartıyorsun. Kabul ama sarma zaten üye işlevler ve erişim hakları ile sağlanabiliyor. Nitelik yapan şu: Üye değişken gibi kullanılmalı ama bir işlev tarafından sunulmalı. O yüzden ben işlev isminde eylem olmasının nitelik kavramına uymadığını düşünüyorum.

Ali

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

Alıntı (acehreli):

> class S
> {
> private:
>     // ...
> public:
>     // ...
> }
> ```

>

Delphi ile çalışırken ve daha sonra C++ ile uğraştığım zamanlar bu yapı banada daha düzenli ve hoş görünüyordu. Hatta C# ile çalışmaya başladığım ilk zamanlar her metodun önüne erişim belirteci yazmak zor bile gelmişti. Ancak daha sonra farkettim ki bence bu hem daha özgür hem daha güvenli hemde daha kolay bir kullanım sunuyordu.

Neticede birazda sürekli kullanmanın verdiği aşinalık ile blok yapısını terk edip bu şekilde tekli tanımı kullanmaya başladım. Doğrusu D dilininde bu yapıyı desteklediğini gördüğümde çok mutlu olmuştum. Zaten D'yi benim gözümde kullanılabilir yapan özelliklerden birisi, geçmişin iyi taraflarını alırken yeni ortaya çıkan özellikleride bünyesinde barındırabilmesi.

Alıntı (acehreli):
>
> Kesinlikle. Anlaşılabildiği sürece her şey otomatik olmalı. Ama bazen farklı olanakların etkileşimleri güçlükler doğurabiliyor.
>

Doğrusu bu UFCS özelliğine bir türlü ısınamadım. İşleri basitleştirmek isterken daha çok karmaşık hale getiriyor gibi geliyor bana, bazen insanların güzel olarak gördüğü bazı özellikler pratikte isteneni veremiyor.

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

Aslında UFCS bir özellik, kullanırsınız veya kullanmazsınız; bu size kalmış. Ama kullanmak isteyenleri kısıtlayıcı yenilikler gelirse bu henüz yeni doğmuş bir bebeğin ölmesi anlamına gelir. Çekirdek geliştiricileri bu serzenişimi bir duysa...:)

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

Alıntı (Salih Dinçer):

Onu daha önce de söyledin. Yanılmıyorsam ECMA bir standartlaşma kurumuymuş. Özellikle ECMAScript dilinin söz dizimine yaklaşmaktan mı bahsediyorsun?

Alıntı:

Seninle aynı fikirde olanlar çok. Bu kural gelene kadar parametre almayan her işlev parantezsiz çağrılabiliyordu. Tartışmaları olmuştu.

Alıntı:

>     Fibonacci.take(100).cycle.writeln;
> ```


Bense Fibonacci yazıldığında bir nesne oluşmasını görmek isterim. Tabii dediğin gibi, cycle ve writeln UFCS'ten yararlanıyorlar onlara diyecek yok. Ama örneğin writeln'ı da yazarı '@property' olarak işaretleyebilir ve parametresiz olarak writeln() diye çağrılacağına yalnızca writeln yazılabilir.

Yalnız Fibonacci'de bile hemen bir sorun görülebiliyor. Abartılı bir örnek ama türün stringof() diye bir üye işlevini tanımlasam, aşağıdaki çağrı Fibonacci türü üzerinde mi stringof'u çağırsın, yani "Fibonacci" mi yazdırsın, yoksa bir nesne oluştursun benim belki de "merhaba" döndürecek biçimde tanımladığım Fibonacci.stringof işlevini mi çağırsın?

   Fibonacci.stringof.writeln;

Yani türün stringof'u mu yoksa otomatik olarak oluşturulan bir nesnenin stringof'u mu? Yanılmıyorsam şablon kodlarında da benzer soru işaretleri oluşabiliyor.

Alıntı:
> 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.

Kesinlikle. Anlaşılabildiği sürece her şey otomatik olmalı. Ama bazen farklı olanakların etkileşimleri güçlükler doğurabiliyor.

Ali

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

Alıntı (Salih Dinçer):

Bir açıdan böyle düşünülebilir. Ancak dile yeni başlayanlar anlamadıkları karışık bu tür yapılar karşısında D dili anlaması zor bir dil gibi yanlış algı içine düşerseler bu sefer durum gerçekten kötü olur. Dolayısyla bir özellik eklenirken etraflıca düşünmek ve tartmak gerekir diye düşünüyorum.

Sözüm UFCS'ye değil ama bana işleri karıştırıyor gibi geldiğini itiraf etmeliyim.

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

Bence de doğru bir karar...

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

Alıntı (zafer):

Benim de kitapta öyle bir sıkıntım var (veya olacak). Geç gelen bir olanak olduğu için UFCS kitapta geçmiyor. Onu İngilizceleştirme sırasında çok yakın bir zaman sonra yeni bir bölüm olarak ekleyeceğim. Ama sanırım "bu olanağı karışıklığa neden olmasın diye örneklerde kullanmayacağım" diyeceğim ve ta en sonlardaki aralıklar bölümüne gelene kadar da yararlanmayacağım. Aralıklar bölümünde de "hani UFCS olanağı vardı ya... bakın yazım kolaylığı sağlıyor" diyeceğim.

Ali

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

Ali sana katılıyorum bencede doğru bir yaklaşım. Çünkü UFCS her nekadar basit bir özellik gibi görünsede arka planında derin bir bilgiye ihtiyaç duyuyor. Kişi bu bilgiye sahipse bu özelliği kullanmasında bir sıkıntı yok bence.

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

Hayret, burada da UFCS konusuna girmişiz ve hatta ilerisi için Ali hocam bazı hedefler belirlemiş. Biliyorum ki bu hedefleri gerçekledi. Bir de kitabın basılı sürümünü elimize alırsak (İstanbul'da şu sıralar kitap fuarı var) süper olacak. Belki 2014 yılında bize bu sürpriz yaparsın ha hocam...:)

Önce şu başlığa referans vereyim: http://ddili.org/forum/post/10344

Burada UFCS'nin bir tehlikeli yanından söz ettim. Gerçi bu bir özellik olmalı. Yani çıkarsama yaparken nesneden başlıyor, bulamazsa dışarıya doğru ve belki başka modüllere kadar ilerliyor olmalı. Orada bir soru soracağımdan bahsetmiştim. İşte şu:

Bir yapımız var ve onun sonlarında doğru şöyle üyelere sahip:

   :    :    :
     int front() const @property {
         return baştaki;
     }

     void popFront() {
         int ikiSonraki = baştaki + sonraki;
         baştaki = sonraki;
         sonraki = ikiSonraki;
     }

     @property:
   :    :    :

Acaba hemen yukarıdaki @property'nin sonunda iki nokta üstüste kullanarak tüm benzer özelliktekileri bir yerde toplamam mümkün olabilir miydi? Gerçi denediğimde derleyici bir hata vermedi ama güzel olurdu hani. Çünkü bazen işlevler, parametreleri ile birlikte uzun olmaktalar ve hatta bazıları static, public, override gibi şeyler de almaktalar. Zaten bu son saydıklarımı bu şekilde yapabiliyoruz.

Peki ya sorduğumuda?

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

Evet, bildiğim kadarıyla öyle. Bütün nitelikler üç biçimde beliltilebiliyor:

@property int yalnızcaBu() { return 42; }

@property:
   // bu bölümdekilerin hepsi

@property {
   // bu kapsamdakilerin hepsi
}

Ali

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