Golang'da “this” kullanımı

Golang'ın burada bulunan bir stil rehberine sahip olduğu en yakın şeyde , Alıcı Adları altında bu yazılmıştır:

Bir yöntemin alıcısının adı, kimliğinin bir yansıması olmalıdır; genellikle türünün bir veya iki harfli kısaltması yeterlidir ("Müşteri" için "c" veya "cl" gibi). "Ben", "bu" veya "ben" gibi genel adları, işlevlerin aksine yöntemlere daha fazla vurgu yapan nesne yönelimli dillerin tipik tanımlayıcılarını kullanmayın. Adının, yöntem açık olduğu ve hiçbir belgesel amaca hizmet etmediği için yöntem argümanının tanımlayıcısı kadar açıklayıcı olması gerekmez.

Ben şahsen her zaman tanımlayıcı olarak "this" i kullandım çünkü "this" işlevi yazarken ve düzenlerken üzerinde çalıştığım şeyin odağı. Kulağa doğru geliyor ve (en azından benim için) mantıklı.

Adın açıklayıcı olması gerekmiyorsa, rolü açıktır ve hiçbir belgesel amaca hizmet etmez , "bu" nun kullanımı neden kaşlarını çatsın?

O stil rehberinin yazarından kesin olarak bilmesini istemeliyiz, ancak bence onunla hemfikir olduğumun ana nedeni, yapı ve yöntem arasındaki bağlantının Go'da diğer dillerden çok daha gevşek olmasıdır .

Özünde, böyle bir yöntem yazdığınızda:

func (m *MultiShape) area() float64 {
  ...
}

Bu, neredeyse böyle bir işlev yazmakla aynı şeydir:

func area(m *MultiShape) float64 {
  ...
}

Tek fark, işlev / yöntem dediğimizde küçük bir sözdizimi değişikliği.

Diğer dillerde this/ self/ whatever değişkeni, tipik olarak dil tarafından sihirli bir şekilde sağlanan veya özel yöntemlere özel erişime sahip olan bazı özel özelliklere sahiptir (Go'nun özel alanlara / yöntemlere sahip olmadığını unutmayın). "Alıcı" hala bir dereceye kadar "sihirli bir şekilde" sağlanmakla birlikte, tartışmasız sayılmayan düzenli bir işlev argümanına çok benzer.

Ayrıca, "geleneksel" OOP dillerinde, bir yapı / sınıf 'yöntemlerinin tümü, yapı / sınıf tanımıyla birlikte gelir, böylece artık dışarıdan eklenemez. Go'da, bildiğim kadarıyla herkes herhangi bir şeye daha fazla yöntem ekleyebilir (elbette kendi kodları kapsamında).

Kendi stil kılavuzumu yapmaya yetecek kadar yazmadım, ama kişisel olarak muhtemelen thisaldıkları yapı ile aynı dosyada tanımlanan yöntemlerde ve diğer dosyalardan gelen yapılara eklediğim yöntemlerde daha açıklayıcı alıcı adı kullanırım .

Bu stil rehberi tarafından ikna olmadım ve hiçbir şeyin daha iyi olduğunu düşünmüyorum this, meya da self. Çünkü this, meveya selfdeğişkenin bağlam yapısının bir örneği olduğunu açıkça belirtir. Daha düşük bir kasa yapısı değişkeninin kötü bir fikir olduğunu söylemiyorum, sadece thissüper netleştiren yolu seviyorum .

Bu, thisderleyiciye gerçek anahtar kelime anlamı olan JavaScript perspektifinden gelir, ancak benim anlayışımdan, nesne türü için iki harfli kısaltmalar ile uygunsa, bunun yerine bunu kullanmak yeterince kolay olmalıdır. Aradaki farkın nedeni, gitgide daha derin olan asenkron kodun terbiyeli olarak büyük bir bloğunda, "bu" nun veya alıcının daha derin bir bağlamda ne olduğunu yanlış yorumlamanın çok kolay olabileceğidir; ve aynı nesne olmayacak.

Örneğin JavaScript'te, bir kontrol modülü bir iletişim kutusu başlatabilir ve onLoadonun için bir işlev satır içi bildirebilir. Ancak bu noktada, başka bir kodlayıcının diyaloğa değil kontrol modülüne başvurmak için thisiçeride yanlış yorumlaması çok kolay olabilir onLoad; ya da tam tersi. Kontrole ctrlve diyalog olarak adlandırılırsa bu önlenebilir dg.