Neden çoğu “iyi bilinen” zorunlu / OO dili, 'hiçbir şey' değeri gösterebilecek türlere denetlenmeden erişime izin veriyor?

(Un) nullyerine (örneğin) sahip olmanın kolaylığını okudum Maybe. Bu makaleyi okuduktan sonra , kullanmanınMaybe (veya benzeri bir şey) daha iyi olacağına ikna oldum . Bununla birlikte, tüm "iyi bilinen" zorunlu veya nesne yönelimli programlama dillerinin (hala null'hiçbir şey' değerini temsil edebilecek türlere denetlenmeyen erişime izin veren) Maybekullandığını ve çoğunlukla işlevsel programlama dillerinde kullanıldığını görünce şaşırdım .

Örnek olarak, aşağıdaki C # koduna bakın:

void doSomething(string username)
{
    // Check that username is not null
    // Do something
}

Burada bir şeyler kötü kokuyor ... Argüman boş olup olmadığını neden kontrol etmeliyiz? Her değişkenin bir nesneye referans içerdiğini varsaymalı mıyız? Gördüğünüz gibi, sorun tanımı gereği hemen hemen tüm değişkenlerin boş bir başvuru içermesidir. Hangi değişkenlerin "null" olduğuna ve hangilerinin olmayacağına karar verebilirsek ne olur ? Hata ayıklama ve bir "NullReferenceException" ararken bu bize çok çaba sarfeder. Varsayılan olarak hiçbir türün boş başvuru içeremeyeceğini hayal edin . Bunun yerine, bir değişkene yalnızca gerçekten ihtiyaç duyduğunuzda boş bir başvuru içerebileceğini açıkça belirtirsiniz . Belki arkasındaki fikir budur. Bazı durumlarda başarısız olan bir işleve sahipseniz (örneğin sıfıra bölme),Maybe<int>, açıkça sonucun bir int olabileceğini, ancak aynı zamanda hiçbir şey olamayacağını da belirterek! Bu, belki null yerine tercih etmek için bir nedendir . Daha fazla örnekle ilgileniyorsanız, bu makaleyi okumanızı öneririm .

Gerçekler, çoğu türü varsayılan olarak null yapmanın dezavantajlarına rağmen, OO programlama dillerinin çoğunun aslında yaptığı gibi. Bu yüzden merak ediyorum:

• nullProgramlama dilinizde yerine ne tür argümanlar uygulamanız gerekir Maybe? Nedenler var mı yoksa sadece "tarihi bagaj" mı?

Lütfen bu soruyu cevaplamadan önce null ve Belki arasındaki farkı anladığınızdan emin olun.

Öncelikle tarihi bir bagaj olduğuna inanıyorum.

En belirgin ve en eski dil nullC ve C ++ dilleridir . Ama burada nullmantıklı. İşaretçiler hala oldukça sayısal ve düşük seviye bir konsepttir. Ve bir başkasının söylediği gibi, C ve C ++ programcılarının zihniyetinde, açıkça bu göstergenin açıklanabileceğini söylemek zorunda olmak bir nullanlam ifade etmiyor.

İkinci sırada Java geliyor. Java geliştiricileri, C ++ 'ya en yakın olanı bulmaya çalıştıklarını düşünürler, böylece C ++' dan Java 'ya geçişi daha basit hale getirebilirlerdi, muhtemelen bu tür bir dil kavramı ile uğraşmak istemiyorlardı. Ayrıca, açık uygulama nullçok daha fazla çaba gerektirecektir, çünkü boş olmayan referansın başlangıçtan sonra doğru bir şekilde ayarlanıp ayarlanmadığını kontrol etmeniz gerekir.

Diğer tüm diller Java ile aynıdır. Genellikle C ++ veya Java'nın yaptığı gibi kopyalarlar ve nullreferans türlerinin temel kavramının ne kadar temel olduğu dikkate alındığında, açık bir dil kullanan bir tasarım yapmak gerçekten zorlaşır null.

Aslında, nullharika bir fikir. Bir işaretçi verildiğinde, bu işaretçinin geçerli bir değere referans göstermediğini belirtmek isteriz. Bu yüzden bir hafıza yeri alırız, geçersiz ilan ederiz ve bu sözleşmeye sadık kalırız (bazen segfaults ile uygulanan bir kongre). Şimdi ne zaman bir işaretçiye sahip olduğumu Nothing( ptr == null) veya Some(value)( ptr != null, value = *ptr) içerip içermediğini kontrol edebilirim . Bunun bir Maybetüre eşit olduğunu anlamanı istiyorum .

Bununla ilgili sorunlar:

1. Birçok dilde, tür sistemi boş olmayan bir referansı garanti etmek için burada yardımcı olmaz.

   Bu, çoğu ana zorunluluk veya OOP dilinin, öncekilerle karşılaştırıldığında tip sistemlerinde yalnızca artan ilerlemelere sahip olması nedeniyle, tarihi bir bagajdır. Küçük değişiklikler, yeni dillerin öğrenilmesinin daha kolay olması avantajına sahiptir. C #, boş değerleri daha iyi ele almak için dil seviyesi araçları tanıtan bir ana dildir.

2. API tasarımcıları nullbaşarısızlıkla sonuçlanabilir, ancak başarıda gerçekleşen şeyin kendisine referans olmayabilir. Genellikle, bir şey (referans olmadan) doğrudan iade edilir. Bir işaretçi seviyesinin bu şekilde düzleştirilmesi, nullbir değer olarak kullanılmasını imkansız kılar .

   Bu tasarımcının tarafında sadece tembellik ve uygun bir tür sistemi ile doğru yuvalama zorlamadan yardım edilemez. Bazı insanlar da bunu performansla ilgili hususlarda veya isteğe bağlı kontrollerin varlığında haklı çıkarmaya çalışabilir (bir koleksiyon geri dönebilir nullveya ürünün kendisi olabilir, ancak bir containsyöntem de sağlayabilir ).

3. Haskell'de Maybetipe bir monad olarak düzgün bir görünüm vardır . Bu, dönüştürülen değeri içerilen değer üzerinde oluşturmayı kolaylaştırır.

   Öte yandan, C gibi düşük seviyeli diller dizileri ayrı bir tür olarak görmezler, bu yüzden ne beklediğimizden emin değilim. Parametreli polimorfizmi olan OOP dillerinde, çalışma zamanı tarafından kontrol edilen bir Maybetürün uygulanması oldukça önemsizdir.

Anladığım kadarıyla nullprogramlama dillerini meclisten soyutlamak için gerekli bir yapıydı. ¹ Programcılar bir işaretçi veya kayıt değerinin olduğunu not a valid valueve nullbu anlam için ortak terim olduğunu belirtme yeteneğine ihtiyaç duyuyorlardı .

nullSadece bir kavramı temsil eden bir kongre noktası olan noktayı güçlendirmek için nullkullanılan gerçek değer programlama dili ve platforma bağlı olarak değişebilir.

Yeni bir dil tasarlıyorsanız ve nullkullanmaktan kaçınmak maybeyerine kullanmak istiyosanız, niyetini belirtmek not a valid valueveya navvbelirtmek gibi daha açıklayıcı bir terim öneririm. Ancak, bu değer olmayanın adı , değerlerin kendi dilinizde var olmasına bile izin vermeniz gerekip gerekmediğinden ayrı bir kavramdır .

Bu iki noktadan herhangi birine karar vermeden önce maybe, sisteminiz için ne anlama geleceğini tanımlamanız gerekir . Bunun nullanlamını sadece yeniden adlandırdığını not a valid valueveya diliniz için farklı bir anlam ifade ettiğini görebilirsiniz.

Aynı şekilde, nullerişim veya başvuruya karşı erişimi kontrol edip etmediğine dair karar, dilinizin başka bir tasarım kararıdır.

Biraz tarih sağlamak için C, programcıların hafızayı değiştirirken ne yapmaya çalıştıklarını anladıklarına dair kesin bir varsayım vardı. Montaj ve önündeki zorunlu diller için üstün bir soyutlama olduğundan, programcının yanlış bir referanstan güvenli bir şekilde korunma fikrinin akıllarına gelmediğini düşünürdüm.

Bazı derleyicilerin veya ek araçlarının geçersiz işaretçi erişimine karşı bir kontrol önlemi sağlayabileceğine inanıyorum. Böylece diğerleri bu potansiyel konuyu not etmiş ve buna karşı korunmak için önlemler almıştır.

Buna izin verip vermemeniz, dilinizin neyi başarmasını istediğinize ve dilinizin kullanıcılarına ne derece sorumluluk vermek istediğinize bağlıdır. Ayrıca, bu tür davranışları sınırlandırmak için bir derleyici oluşturma yeteneğinize de bağlıdır.

Yani sorularınızı cevaplamak için:

1. “Ne tür argümanlar…” - Peki, dilin ne yapmasını istediğine bağlı. Çıplak metal erişimini simüle etmek istiyorsanız, izin vermek isteyebilirsiniz.

2. "Bu sadece tarihi bir bagaj mı?" Belki de belki de değil. nullelbette bir çok dil için bir anlamı vardı / vardır ve bu dillerin ifadesini yönlendirmeye yardım eder. Tarihsel emsal daha yeni dilleri ve onların izinlerini etkilemiş olabilir, nullancak ellerinizi el sallamak ve kavramı işe yaramaz tarihsel bagaj olarak ilan etmek biraz daha fazla.

¹ Boş değerler ve nesne yönelimli diller için Hoare'e kredi verilse de bu Wikipedia makalesine bakın . Zorunlu dillerin Algol'dan farklı bir soy ağacında ilerlediğine inanıyorum.

Alıntı yaptığınız makaledeki örneklere bakarsanız, çoğu zaman Maybekodu kısaltmaz. Kontrol etme ihtiyacını ortadan kaldırmıyor Nothing. Aradaki tek fark, bunu tür sistemi üzerinden yapmayı hatırlatmasıdır.

Not, zorlamak değil "hatırlatmak" diyorum. Programcılar tembel. Eğer bir programcı bir değerin olamayacağına ikna olmuşsa Nothing, Maybekontrol etmeden onaysızlaştırmaya başlayacaklar , tıpkı şimdi boş bir göstergeye başvurdukları gibi. Sonuçta boş gösterici istisnasını "belki boş belki" istisnasına dönüştürürsünüz.

Aynı insan doğası prensibi, programlama dillerinin programcıları bir şeyler yapmaya zorladığı başka alanlarda da geçerlidir. Örneğin, Java tasarımcıları insanları istisnaların çoğunu ele almaya zorlamaya çalıştı; bu durum, istisnaları sessizce görmezden ya da göz ardı eden bir şekilde çoğaltan birçok kazan plakasıyla sonuçlandı.

İşe yaramaz Maybeolan şey, açık kontroller yerine desen eşleştirme ve polimorfizmle çok fazla karar verilmesidir. Örneğin, ayrı işlevler oluşturabilirsiniz processData(Some<T>)ve processData(Nothing<T>)bunlarla yapamazsınız null. Hata işleme fonksiyonunuzu otomatik olarak, fonksiyonların her zaman yukarıdan aşağıya çağrılmak yerine, temkinli olarak değerlendirildiği ve fonksiyonların geçtiği fonksiyonel programlamada çok arzulanan ayrı bir işleve taşır. OOP'de, hata işleme kodunuzu ayırmanın tercih edilen yolu istisnalardır.

Maybebir problemi düşünmenin çok fonksiyonel bir yoludur - bir şey vardır ve tanımlanmış bir değeri olabilir veya olmayabilir. Bununla birlikte, nesne yönelimli bir anlamda, bir şey hakkındaki fikrini (değeri olsun veya olmasın) bir nesneyle değiştiririz. Açıkçası, bir nesnenin bir değeri vardır. Olmazsa, nesnenin olduğunu söyleriz null, ancak gerçekten demek istediğimiz, hiçbir nesnenin olmamasıdır. Nesneye gönderdiğimiz referans hiçbir şeye işaret etmez. Çevriliyor Maybebir OO kavramının içine hiçbir şey roman yapar - aslında, bu sadece daha fazla oranda darmadağın kodu için yapar. Değeri için hala boş bir referansa sahip olmanız gerekir.Maybe<T>. Şimdi "belki çek" olarak adlandırılsalar bile, hala boş kontroller yapmalısınız (aslında, daha fazla boş kontrol yapmanız, kodunuzu bozmanız). Elbette, yazarın iddia ettiği gibi daha sağlam bir kod yazacaksınız, ancak bunun sadece durum olduğunu iddia ediyorum, çünkü çoğu zaman gereksiz olan bir çalışma düzeyi gerektiren dili çok daha soyut ve anlaşılır kılıyordunuz. İsteyerek bir süre NullReferenceException alırdım spagetti koduyla uğraşmak yerine belki yeni bir değişkene her giriş yaptığımda bir kontrol yapabilirim.

Kavramı nullkolayca C'ye kadar uzanabilir, ancak problemin olduğu yer burası değildir.

Gündelik seçim dilim C # ve nulltek bir farkla tutardım. C # iki tür tip, değer ve referansa sahiptir . Değerler asla olamaz null, ancak hiçbir değerin tamamen iyi olmadığını ifade edebilmek istiyorum. Bunu yapmak için C # Nullabletürünü kullanır, böylece intdeğer ve int?boş değer olur. Referans türlerinin de çalışması gerektiğini düşünüyorum.

Ayrıca bakınız: Boş başvuru bir hata olmayabilir :

Boş referanslar yararlı ve bazen vazgeçilmezdir (C ++ 'da bir dize döndürürseniz veya döndürmezseniz ne kadar sorun olduğunu düşünün). Hata, boş göstericilerin varlığında değil, tip sisteminin onları nasıl ele aldığına bağlı. Ne yazık ki çoğu dilde (C ++, Java, C #) bunları doğru bir şekilde işlemez.

Bunun nedeni işlevsel programlamanın türler , özellikle de nesne yönelimli programlamanın (veya en azından başlangıçta yaptığınız gibi) diğer türleri birleştiren türler (tekiller, birinci sınıf türler, işlevler, monadlar, vs.).

Programlama dillerinin modern versiyonlarından bahsettiğinizi düşünüyorum (C ++, C #, Java), genel olarak herhangi bir genel programlama biçimine sahip olmayan dilleri temel alır (C, C # 1.0, Java 1). Bu olmadan, hala null ve null olmayan nesneler arasında dile bir tür fark yaratabilirsiniz (C ++ referansları gibi, olamaz nullama aynı zamanda sınırlıdır), ama bu daha az doğaldır.

Bence temel sebep, bir programın veri bozulmasına karşı "güvenli" hale getirilmesi için nispeten az sayıda boş denetim yapılması gerektiğidir. Bir program, bir dizi öğesinin içeriğini veya geçerli bir referansla yazılmış olması öngörülen başka bir depolama konumunun içeriğini kullanmaya çalışırsa, en iyi sonuç, bir istisna atılmasıdır. İdeal olarak, istisna sorunun tam olarak nerede gerçekleştiğini gösterecektir, ancak boş referans, verilerin bozulmasına neden olabilecek bir yerde saklanmadan önce bir tür istisna ortaya çıkması önemlidir. Bir yöntem ilk önce onu kullanmaya çalışmadan bir nesneyi saklamadığı sürece, bir nesneyi kullanma denemesi - kendi başına - bir tür "boş denetim" oluşturacaktır.

Eğer biri haricinde belirli bir istisnaya neden olmayacak gibi görünen boş bir referansın olmasını sağlamak isterse NullReferenceException, genellikle her yere boş kontroller eklemek gerekecektir. Öte yandan, yalnızca boş bir referansın, önceden yapılmış olanların ötesinde “hasara” yol açmasından önce bir istisna oluşmasını sağlamak genellikle çok az test gerektirecektir - testler genellikle sadece bir nesnenin depolanacağı durumlarda gerekli olacaktır. kullanmaya çalışınca olmadan referans, ve ya boş bir başvuru geçerli bir adres üzerine yazılacağı, ya da programın devletin yanlış anlaşılabilir diğer yönlerine başka kod neden olur. Bu tür durumlar var, ama hepsi bu kadar yaygın değil; yanlışlıkla yapılan en null referanslar çok çabuk yakalanırbirinin onları kontrol edip etmediği .

" Maybe," yazıldığı gibi, sıfırdan daha yüksek bir yapıdır. Tanımlamak için daha fazla kelime kullanmak, Belki de "bir şeye işaretçi veya hiçbir şeye işaretçi değil, ama derleyiciye hangisine karar vermesi için yeterli bilgi henüz verilmemiş." Bu, yazdığınız koda ayak uyduracak kadar akıllı bir derleyici özelliği oluşturmadığınız sürece, her bir değeri sürekli olarak açıkça kontrol etmeye zorlar.

Belki kolayca nulls bir dil ile bir uygulama yapabilirsiniz. C ++ şeklinde bir tane vardır boost::optional<T>. Belki ile null eşdeğerini yapmak çok zor. Özellikle, eğer varsa Maybe<Just<T>>, onu null olarak atayamam (çünkü böyle bir kavram yoktur), T**null olan bir dilin null değerine atanması çok kolaydır. Bu Maybe<Maybe<T>>, tamamen geçerli olan birini kullanmaya zorlar , ancak sizi bu nesneyi kullanmak için daha fazla kontrol yapmaya zorlar.

Bazı işlevsel diller Belki kullanır, çünkü boş, tanımlanmamış davranış veya istisnaların işlenmesini gerektirir, bunların hiçbiri işlevsel dil sözdizimleriyle eşleştirilmesi kolay bir kavram değildir. Belki de bu tür işlevsel durumlarda rolü daha iyi doldurur, ancak usul dillerinde null kraldır. Bu doğru ve yanlış meselesi değil, sadece yapmasını istediğiniz şeyi yapmasını bilgisayara söylemeyi kolaylaştıran şeydir.