Od czego zależy, czy w danym języku dozwala się robić unqualified import czy też żąda się zawsze pisania namespace?

Odpowiedz Nowy wątek
2019-06-08 14:06
0

Uwaga uwaga poniżej największa zbrodnia programisty C++ wystrzegać się jej zawsze

using namespace std;

Czy ja jestem osamotniony w tym, że uważam, że pisanie wszędzie co chwila std:: tylko zaciemnia kod, zaśmieca go i w ogóle jest zbędne?

Ale jednak przyjęło się, że using namespace cokolwiek dopuszczalne jest tylko i wyłącznie w ciele funkcji; na górze pliku jest niedopuszczalne.

Mam pytanie, może głupie, ale naprawdę nie wiem. Jak mamy taki C# na przykład, to czy dozwala się napisać na górze pliku:

using System.Collections.Generic;

I potem pisać już sobie tylko List zamiast obowiązkowo wszędzie System.Collections.Generic.List? Czy też może unqualified wildcard import jest zabroniony także w C#?

To samo pytanie dotyczy także rozmaitych Pythonów, Jav, i innych.

W skrócie: Czy ten zakaz jest charakterystyczny dla C++ czy dla języków programowania w ogóle?

Pozostało 580 znaków

2019-06-08 14:13
0

W Javie masz zwykle pojedynczy import:
import java.util.ArrayList;
Wildcardy widuje się znacznie rzadziej:
import java.util.*;


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2019-06-08 14:17
0
Wibowit napisał(a):

W Javie masz zwykle pojedynczy import:
import java.util.ArrayList;
Wildcardy widuje się znacznie rzadziej:
import java.util.*;

Aha. Czy zatem w C++ dopuszczalne jest:

    #include <iostream>
    #include <vector>
    using std::vector;
    using std::cout;
    using std::endl;

    int main() {
        vector<int> v{1,2, 3, 4};
        for(auto i : v) cout << i  << endl;
        return 0;
    }

Czy też jest to zabronione?

WYDAJE MI SIĘ, że też jest zabronione; mamy więc różnicę między C++ a Javą. Skąd się ona wzięła, jeśli rzeczywiście jest?

Pozostało 580 znaków

2019-06-08 14:26
0

Język niczego nie narzuca. Dogadaj się z kumplami z pracy w jakim stylu chcecie pisać. Natomiast jeśli wszyscy w C++ dziwnie piszą to zmień język :)


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2019-06-08 14:30
0

Rzekomo w C++ ma to głębokie uzasadnienie.

1) W pliku nagłówkowym jakiekolwiek using cośtam na górze przenosi się dla wszystkich plików importujących ten nagłówek;

2) using namespace cośtam nawet w pliku implementacyjnym to proszenie się o kłopoty, bo jeśli jakaś moja funkcja / klasa ma tę samą nazwę co biblioteczna, to bez dokładnego zorientowania się, co eksportuje biblioteka i ogarniania reguł overloadingu mogę nawet nie orientować się, co jest wołane i że nie to, co bym chciał, by było wołane; co gorsza: nawet jak raz napiszę program i jest poprawny, potem aktualizuję bibliotekę która dodaje nowe funkcje to na nowej bibliotece może mi już przestać działać z tego powodu;

3) Jeszcze jakies inne jeszcze bardziej techniczne uzasadnienia, których już nie pamiętam.

Pozostało 580 znaków

2019-06-08 14:38
0

Jeśli using namespace std; importuje także metody to jest to zupełnie co innego niż zwykły import z Javy. Żeby zaimportować metody w Javie trzeba zrobić coś takiego: import static org.apache.commons.io.IOUtils.*;
Jest to jeszcze rzadsze niż importowanie klas hurtem: import jakaś.paczka.*;

1) W pliku nagłówkowym jakiekolwiek using cośtam na górze przenosi się dla wszystkich plików importujących ten nagłówek;

Noo, brzmi jak proszenie się o problemy, więc tutaj bym się zgodził, że takie importowanie nie powinno mieć miejsca.

2) using namespace cośtam nawet w pliku implementacyjnym to proszenie się o kłopoty, bo jeśli jakaś moja funkcja / klasa ma tę samą nazwę co biblioteczna, to bez dokładnego zorientowania się, co eksportuje biblioteka i ogarniania reguł overloadingu mogę nawet nie orientować się, co jest wołane i że nie to, co bym chciał, by było wołane; co gorsza: nawet jak raz napiszę program i jest poprawny, potem aktualizuję bibliotekę która dodaje nowe funkcje to na nowej bibliotece może mi już przestać działać z tego powodu;

Jak często zdarzają się takie problemy? Może trzeba niewiele zmian w stylu pisania kodu, by takich problemów uniknąć?

Problemy powinny generalnie zostać wychwycone przez testy.

Czy ja jestem osamotniony w tym, że uważam, że pisanie wszędzie co chwila std:: tylko zaciemnia kod, zaśmieca go i w ogóle jest zbędne?

Są tacy co dodają namiętnie zbędne this. przed wywołaniami metod i jeszcze twierdzą, że to zwiększa czytelność kodu.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 5x, ostatnio: Wibowit, 2019-06-08 14:46

Pozostało 580 znaków

2019-06-08 14:42
1

W c# tylko takie podejścia widziałem

using System.Collections.Generic;

namespace something
{
    public class someclass
    {

    }
}
namespace something
{
    using System.Collections.Generic;

    public class someclass
    {

    }
}

A gdy występuje konflikt to się precyzuje.

edytowany 2x, ostatnio: WeiXiao, 2019-06-08 14:42

Pozostało 580 znaków

2019-06-08 14:43
0

Zdefiniuj: metody.

Przecież C++ wspiera funkcje nie będące metodami:

#include <iostream>

int jestem_sobie_funkcja(int i)
{
    return i + 2;
}

class WaznaIPowaznaKlasa
{
public:
    static int jestem_sobie_metoda(int i)
    {
       return i+2;
    }
};

int main()
{
    std::cout<< jestem_sobie_funkcja(5) << '\t';
    std::cout << WaznaIPowaznaKlasa::jestem_sobie_metoda(6) << '\n';
    return 0;
}

using namespace cośtam importuje funkcje, ale nie metody. (A przynajmniej tak mi się wydaje.)

co masz na myśli pisząc importuje??? - Miang 2019-06-08 15:49
Wprowadza do głównej przestrzeni nazw. Wiem, nieściśle się wyraziłem. - kmph 2019-06-09 12:41

Pozostało 580 znaków

2019-06-08 14:49
0

No dobra, trochę Javizmami poleciałem :] W Javie statyczne metody to mniej więcej to samo co w C++ globalne funkcje. Chodziło mi właśnie o to.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Pokaż pozostałe 22 komentarze
@Wibowit: ja nie widzę związku, dlatego pytam. Natomiast moje główne pytanie jest związane z tym zdaniem, które napisałeś: Metoda nie ma typu, bo nie jest wartością - na natomiast typ zwracany. Nie rozumiem go. Jak można nie mieć typu, ale mieć typ zwracany? - Silv 2019-06-08 16:40
No trochę nieprecyzyjnie napisałem. Chciałem napisać: nie ma typu, który możesz zapisać w kodzie jako typ wartości. Nie możesz napisać w Javie: TypMetody wartość = obiekt.metoda; Możesz za to podnieść metodę do obiektu typu Function, np Function<A, B> wartość = obiekt::metoda; - czyli stworzyć obiekt, który wywoła metodę obiekt.metoda. Zresztą (przynajmniej w Scali, ale też pewnie i w Javie) za każdym razem ludzie używają stwierdzenia sygnatura metody, a nie typ metody. - Wibowit 2019-06-08 16:49
Czy masz na myśli to, że "funkcje" w Scali są to tzw. first-class functions, tak jak jest tu opisane: https://developer.mozilla.org[...]Glossary/First-class_Function ? - Silv 2019-06-08 16:55
Tak. Funkcje są https://en.wikipedia.org/wiki/First-class_citizen a metody nie oraz istnieje prosta metoda (lifting - podnoszenie) konwersji metody na funkcję. - Wibowit 2019-06-08 16:58
To już mniej-więcej rozumiem to, co chciałem zrozumieć. :) Dzięki! - Silv 2019-06-08 17:00

Pozostało 580 znaków

2019-06-08 14:51
0

No ale przecież C++ także wspiera statyczne metody obok globalnych funkcji. Więc to nie do końca to samo

edytowany 1x, ostatnio: kmph, 2019-06-08 14:51
a jaka jest różnica, oprócz składni? - Wibowit 2019-06-08 14:52
using namespace cośtam; importuje jedne, ale już nie drugie? statyczne metody mogą być prywatne? Tak z głowy tylko - kmph 2019-06-08 14:53
a using Klasa nie importuje statycznych metod? - Wibowit 2019-06-08 14:54
Nie wiem, zaraz sprawdzę - kmph 2019-06-08 14:54

Pozostało 580 znaków

2019-06-08 15:11
0
Wibowit napisał(a):

Problemy powinny generalnie zostać wychwycone przez testy.

To już grozi dygresją i pojechaniem poza główny temat, ale trudno.

Wydaje mi się, że tu są dwie szkoły: Jedna głosi, że unit testy >> statyczne sprawdzanie poprawności przez kompilator, a druga, że jest dokładnie na odwrót.

I tak np. Uncle Bob potępia Kotlin i Swift z tego powodu, że one idą w kierunku wyłapywania błędów w czasie kompilacji kosztem, wg U.Boba, uprzykrzania życia programiście piszącego kod: https://blog.cleancoder.com/u[...]b/2017/01/11/TheDarkPath.html

A z kolei proponenci tego drugiego podejścia idą w kierunku, że "jeśli się kompiluje, to jest już 90% szans, że jest poprawne" i że to jest właśnie wygodne podejście. (W szczególności ta zaleta jest często podnoszona w przypadku Haskella chyba)

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0