Thread overview
Özellikden Kastettiğimiz
October 05

Merhaba Ali Hocam,

Önceki başlıkta şöyle bir cevabınız vardı:

On Tuesday, 4 October 2022 at 18:36:53 UTC, Ali Çehreli wrote:

>

On 10/2/22 23:13, Ali Çehreli wrote:

>

On 10/2/22 20:30, Salih Dincer wrote:

> >

Gerçi nesne/işlevlerdeki yüklem (predicate) ifadelerini
sevmediğinizi
biliyordum ve eminim kendinize göre haklı sebepleriniz
vardır.

"Yüklem"i yanlış mı kullandım? "Fiil" daha mı doğruydu? Yanlış
anlaştığımız kesin çünkü predicate de severim yüklem de. (?)
:)

O konuyu geç anladım: Nitelik (property) işlevlerinde sevmiyorum. Örneğin, .getLength() yerine .length() olmalı.

Eğer işlev bir iş görüyorsa örneğin dosyaOluştur() gibi olmalı.

Ali

Yabancı forumda @property kullananlar oylanırken (sanırım Rikki Cattermole açmıştı) 4. sayfanın sonunda, mealen (çeviride hata olabilir) şöyle özetlendi:

02/10/2022 03:12'de Dom DiSc şunu yazdı:

> >

@property kazanımları nelerdir ve "özellik" tarafına çekilmelidir?

Bir üyeye erişim üzerinde kontrol sahibi olmanızı sağlar

  • okuyabilirsiniz (getter varsa)
  • yazabilirsiniz (setter varsa)
  • üzerinde hem okuyan hem de yazan işlemleri uygulayabilirsiniz (hem getter hem de setter varsa ++ gibi)
  • adresini alamazsınız (bunu istiyorsanız işlevi veya değişkeni kullanın)

Tabi şu an büyük tartışma konusu çünkü kodların kırılmaması için kullanmayın deniyor. Ama en basitten std.array.Appender'da onlarla dolu. Hatta Phobos'a baktığımızda her yerde karşınıza çıkabilir. Neyse bu ayrı bir konu...

Ali hocanın bahsettiği, kelimelere verdiğimiz anlamı haketmesi veya sahip olduğumuz kazanımları karşılaması açısından iyi seçim yapmak gerekiyor. Yoksa aradan uzun zaman geçtiğinde siz bile anlamayacaksınız :)

Hocam bilmiyorum konuyu doğru yerden mi başlattım. Size cevaben ise ben kendi değişkenlerime doğrudan erişilmeyip getter/setter özelliklerini kullanmaya bayılıyorum. Ama D bu konuda bizim elimizden tutmuyor ve herkes bildiğini okuyor tabi :)

Aslında .length olayı oturdu ve sanırım herkes kullanıyor. Ama ben bazen ona parametre aldırıyorum. Çünkü kendi türümde bana neyin uzunluğunu vereceğini iyi tasarlayamıyorum. Bir sürü de .length olmasın diye varsayılan parametre ile birlikte kullanıyorum. Eğer T.sizeof gibi bir şeyi döndürmesini istersem atıyorum şöyle bir şey:

auto length(bool bitLength = false) {
  size_t result;
  // ...
  return result;
}

Yukardaki gibi olan bir işlevi kendiTürüm.length(true) şeklinde kullanıyorum. Tabi bu basit olan ve şu an aklıma gelen. Sanırım enum'lar kullanmıştım. Şimdi hatırlayamadım ama konusu geçerse örnek kodları bulup paylaşırım.

Eminim yukardaki verdiğim örneğe şöyle bir gülümsediniz :)

Ben de anlamsız buluyorum ve gerçi böyle bir işlev yazmamışımdır (sanırım!) yani belirsizlik var çünkü. Bu durumda bitLength() isminde ayrı bir işlev gerekir. Neyse çok uzattım.

Sevgiler, saygılar...

October 05
On 10/5/22 16:05, Salih Dincer wrote:

> (çeviride hata olabilir)

Tabii var. :)

  What '@property' gains or should gain over '// property'?

Denmiş ve şöyle çevirilmiş:

  `@property` kazanımları nelerdir ve "özellik" tarafına çekilmelidir?

Doğrusu şu:

  '// property' yerine '@property' kullanmanın getirisi nedir (veya ne olmalıdır)?

> Tabi şu an büyük tartışma konusu çünkü kodların kırılmaması için
> kullanmayın deniyor.

@property'nin tek etkisi var: Üyenin türü alındığında işlev göstergesi mi olsun, üyenin döndürdüğü tür mü olsun? Şöyle bir kod:

struct S {
              int a() { return 0; }
    @property int b() { return 0; }
}

pragma(msg, typeof(S.init.a));
pragma(msg, typeof(S.init.b));

Derlenirken ekrana şunu yazar:

int()
int

Yani 'a' için "bu int döndüren bir işlevdir" dendiği halde 'b' için "bu bir int'tir" deniyor.

Sorulan soru onunla ilgili: @property'nin günümüzdeki etkisi bu kadar ucubik iken yine de kullanıyor musunuz?

D belgeleri ise @property'yi günümüzde önermiyor. Anlamı ileride genişletilebilir ve daha kullanışlı hale getirilebilir.

> Ama en basitten `std.array.Appender`'da onlarla
> dolu. Hatta Phobos'a baktığımızda her yerde karşınıza çıkabilir. Neyse
> bu ayrı bir konu...

Herhalde kimse Phobos'u @property'den temizlememiş. Önerilmiyor ama hemen kaldırılması da şart değil.

> kendi değişkenlerime doğrudan erişilmeyip getter/setter özelliklerini
> kullanmaya bayılıyorum.

Ben dahil herkes de bayılıyor. Soru, '@property' yazıp yazmamakla ilgili. Yazmasak da foo.length diyebiliyoruz zaten ya...

> Ama D bu konuda bizim elimizden tutmuyor ve
> herkes bildiğini okuyor tabi :)

Ona katılmıyorum. Çoğu programcı açıkça erişilmelerinde sakınca olan üyeleri işlevler arkasına gizler.

Ama o da yalnızca gerektiğinde kullanılmalıdır. Şöyle bir yapı olsun:

struct Nokta {
  int x;
  int y;
}

Onun yerine şu daha mı iyi?

struct Nokta {
private:

  int x_;
  int y_;

public:

  int x() const { return x_; }
  int y() const { return y_; }
}

Hayır, daha iyi değil çünkü koordinat gibi yalnızca 'veri' taşıyan ve üyeleri arasında hiçbir ilişki bulunmayan bir türü neden gürültüye boğalım? Bugün üstteki Nokta'yı yazar kullanırım, yarın gerekirse ikinci Nokta'ya dönüştürürüm.

> Yukardaki gibi olan bir işlevi `kendiTürüm.length(true)` şeklinde
> kullanıyorum.

Okunaklı olmaz çünkü kendiTürüm.length(true) ve kendiTürüm.length(false)... ??? :)

(Hazır isimlerden de bahsetmişken, gereksiz bir not: kendiTürüm de yanlış olur, değil mi? Örnek kod bile olsa kendiDeğişkenim veya kendiNesnem olmalı.)

> Tabi bu basit olan ve şu an aklıma gelen. Sanırım enum'lar
> kullanmıştım.

enum olur ama şundan daha mı iyi olur?

  kendiNesnem.bitLength;
  kendiNesnem.byteLength;

Bakalım:

  kendiNesnem.length(BenimEnum.bit);
  kendiNesnem.length(BenimEnum.byte_); // byte anahtar sözcüğünü kullanamam

> `bitLength()` isminde ayrı bir işlev gerekir.

Bence de bitLength ve byteLength kazanıyor.

Ali


October 09

On Wednesday, 5 October 2022 at 23:28:37 UTC, Ali Çehreli wrote:

> >

Ama D bu konuda bizim elimizden tutmuyor ve
herkes bildiğini okuyor tabi :)

Ona katılmıyorum. Çoğu programcı açıkça erişilmelerinde sakınca olan üyeleri işlevler arkasına gizler.

Ama o da yalnızca gerektiğinde kullanılmalıdır. Şöyle bir yapı olsun:

  int x;
  int y;
}

Onun yerine şu daha mı iyi?

struct Nokta {
private:

  int x_;
  int y_;

public:

  int x() const { return x_; }
  int y() const { return y_; }
}

Hayır, daha iyi değil çünkü koordinat gibi yalnızca 'veri' taşıyan ve üyeleri arasında hiçbir ilişki bulunmayan bir türü neden gürültüye boğalım? Bugün üstteki Nokta'yı yazar kullanırım, yarın gerekirse ikinci Nokta'ya dönüştürürüm.

Peki hocam, 2 sorum var:

Birincisi, aşağıdaki gibi 20 küsür satırlık bir yapıda getter/setter işlevlerine ihtiyacımız yok muydu?

struct Point
{
  union
  {
    uint points;
    ushort[2] p;
  }
  // getters:
  uint x() { return p[1]; }
  uint y() { return p[0]; }
  // setters:
  auto x(ushort n) { p[1] = n; }
  auto y(ushort n) { p[0] = n; }

  string toString()
  {
    import std.format;
    return format("%08X", points);
  }
} unittest {
  auto n = Point(uint.max);
  assert(n.points == 0xFFFF_FFFF);
  assert(n.x == ushort.max);
  assert(n.y == ushort.max);
}

Vardı çünkü ben grafik çalışırken böyle şeyleri elimin altında tutup template marifeti ile kullanmayı seviyorum. D ne yapıyor (?) peki @property konusunda tembellik yapıp tanımlamıyor (!) ve bana bunu otomatik veremiyor, beni serbest bırakıyor :)

İkincisi, bunun setter işlevlerini return'lü olarak şu şekilde kurgulasaydık avantajımız ne olurdu?

  // setters:
  auto x(ushort n) { return p[1] = n; }
  auto y(ushort n) { return p[0] = n; }

Aslında cevabı biliyorum, çünkü aynı satırda etkileşebilir (örneğin ekrana yazabilir) ya da aşağıdaki assert'de olduğu gibi hemen tek satırda doğrulayabilirdik:

import std.stdio;
void main()
{
  auto point = Point();
  with(point) {
    x(10).writeln; // "10"
    y(11).writeln; // "11"
    points.writefln!"%08X"; // "000A000B"
  }
  assert(point.x(1) + point.y(9) == 0x0A);
  point.writeln; // "00010009"
}

Yanıtlarınız için teşekkürler, şu sıralar çok kod yazamıyorum. Geç cevap için üzgünüm yoksa yazışacak çok konu var. :)

Sevgiler, saygılar...

October 09

On Sunday, 9 October 2022 at 20:15:08 UTC, Salih Dincer wrote:

>

Birincisi, aşağıdaki gibi 20 küsür satırlık bir yapıda [...]

struct Point
{
  union
  {
//...

Aslında D, o kadar güzel bir dil ki 10 satırada da bir union kurarak benzer şeyler yapılabiliyor. İşte 2 eksiği var ve birincisi yakında olacak sanırım:
1.'si kısa yazımı desteklemesi ki aşağıdaki kodda süslü parantez ve return yerine doğrudan yazabileceğiz,

2.'si, şu Allah'ın cezası @property'nin hakkını verseler ya (!) neyse şimdi ağzımı açmıyorum çok fazla. Yoksa Walter'a çok söylenecek söz var :)

union Point
{
  uint points;
  ushort[2] p;

  @property x() { return p[1]; }
  @property y() { return p[0]; }

  @property x(ushort n) { return p[1] = n; }
  @property y(ushort n) { return p[0] = n; }

/* Şahsen şunu yapabilmek isterdim:

  @property {
    x(ushort n) => p[1] = n;
    y(ushort n) => p[0] = n;
  }
*/
}

import std.stdio;
void main()
{
  with(new Point())
  {
    x = 10;
    y = 11;
    points.writefln!"%08X"; // "000A000B"
    assert( x(1)
          + y(9)
        == 0x0A);
  }
}

Başarılar...

October 09
On 10/9/22 13:15, Salih Dincer wrote:

> **Birincisi**, aşağıdaki gibi 20 küsür satırlık bir yapıda getter/setter
> işlevlerine ihtiyacımız yok muydu?
>
> ```d
> struct Point
> {
>    union
>    {
>      uint points;
>      ushort[2] p;
>    }
>    // getters:
>    uint x() { return p[1]; }
>    uint y() { return p[0]; }

p[1]'e x diye p[0]'a y diye hitap ettiğimize göre evet, ihtiyacımız varmış.

> Vardı çünkü ben grafik çalışırken böyle şeyleri elimin altında tutup
> template marifeti ile kullanmayı seviyorum. D ne yapıyor (?) peki
> `@property` konusunda tembellik yapıp tanımlamıyor (!) ve bana bunu
> otomatik veremiyor, beni serbest bırakıyor :)

Anlamıyorum. Yani D bütün türleri ushort, ubyte vs. gibi diziler gibi tanımlasaydı ve biz hangi parçalarının x, y, vs. diye kullanılaacağını @property ile mi belirleyebilseydik?



> **İkincisi**, bunun setter işlevlerini return'lü olarak şu şekilde
> kurgulasaydık avantajımız ne olurdu?
> ```d
>    // setters:
>    auto x(ushort n) { return p[1] = n; }
>    auto y(ushort n) { return p[0] = n; }
> ```
> Aslında cevabı biliyorum, çünkü aynı satırda etkileşebilir (örneğin
> ekrana yazabilir) ya da aşağıdaki `assert`'de olduğu gibi hemen tek
> satırda doğrulayabilirdik:

Eğer çok kullanılacaksa kabul. Ama sırf bazen öyle kullanabilelim diye o "setter"ların daha masraflı derlenmesi belki istenmiyordur. (?) Masraflı olur (herhalde) çünkü bir de dönüş değerinin kullanan tarafa aktarılması işi vardır. Ve belki değer int olduğunda önemsizdir ama kullanıcı türlerinde derlenen kod masraflı oluyordur.

Ali


November 19

On Sunday, 9 October 2022 at 22:59:30 UTC, Ali Çehreli wrote:

>

On 10/9/22 13:15, Salih Dincer wrote:

>

Birincisi, aşağıdaki gibi 20 küsür satırlık bir yapıda
getter/setter
işlevlerine ihtiyacımız yok muydu?

struct Point
{
   union
   {
     uint points;
     ushort[2] p;
   }
   // getters:
   uint x() { return p[1]; }
   uint y() { return p[0]; }

p[1]'e x diye p[0]'a y diye hitap ettiğimize göre evet, ihtiyacımız varmış.

>

Vardı çünkü ben grafik çalışırken böyle şeyleri elimin
altında tutup
template marifeti ile kullanmayı seviyorum. D ne yapıyor (?)
peki
@property konusunda tembellik yapıp tanımlamıyor (!) ve
bana bunu
otomatik veremiyor, beni serbest bırakıyor :)

Anlamıyorum. Yani D bütün türleri ushort, ubyte vs. gibi diziler gibi tanımlasaydı ve biz hangi parçalarının x, y, vs. diye kullanılaacağını @property ile mi belirleyebilseydik?

Hocam bu soruyu cevaplamamışım. Kusura bakmayın ve o gün neyi katettiğimi hatırlamıyorum. O yüzden özür dilerim ama isterseniz altı dolu olan benzer bir konuyla devam edelim:

https://forum.dlang.org/post/nweemnsoctbmhhttkvgk@forum.dlang.org

Sevgiler, saygılar...