3 października 2007

Aliasy dla nazw importowanych klas

Jakiś czas temu przyszedł mi do głowy bardzo prosty i zdawałoby się genialny w swej prostocie pomysł, aby umożliwić nadawanie aliasów importowanym klasom. Wyobraźmy sobie kod, który jednocześnie używa wielu klas o tej samej nazwie a pochodzących z różnych pakietów. Przykładowo java.sql.Date i java.util.Date. Póki co nie ma wyjścia – musimy używać w pełni kwalifikowanych nazw klas. Rozwiązanie problemu wydaje się oczywiste – wystarczyło by udostępnić składnie zademonstrowaną poniżej lub jakąś analogiczną:

import java.util.Date;
import java.sql.Date as SqlDate;

Znaczenie takiej konstrukcji jest chyba oczywiste. Co więcej, takie rozszerzenie języka jest bardzo łatwe do zaimplementowania, jako że jest to tylko lukier syntaktyczny (składniowy). Pomysł ten powrócił do mnie dzisiaj i tym razem zadałem sobie trud sprawdzenia, co Internet ma do powiedzenia w tej sprawie. Okazuje się, że pomysł mój jest całkiem rozsądny, jako że ten sam pomysł mieli też inni ludzie i co więcej zarejestrowali go jako propozycję rozszerzenia (ang. request for improvement) języka Java. Problem był zgłaszany kilkukrotnie, ale najbliżej tego, co powyżej przedstawiłem jest zgłoszenie w BugDatabase numer 4194542. Skoro pomysł jest rozsądny i łatwy w implementacji to czemu jeszcze tego nie mamy? Po lekturze komentarzy pod propozycjami wprowadzenia tego lub podobnego rozszerzenia mogę wskazać dwa kontrargumenty. Pierwszy natury praktycznej – te same klasy mogły by mieć różne nazwy w różnych fragmentach kodu, jako że nic nie mogłoby powstrzymać nas od nadania tej samej klasie różnych aliasów w zależności od sytuacji. Jest to niewątpliwie kontrargument wart rozważenia. Drugi to już bardziej filozofia – należy rozważnie wprowadzać nowe elementy składni, aby język nie rozrósł się zanadto. Język Java ma już jednak w tej chwili kilka konstrukcji składniowych, które można by, kierując się tym tokiem rozumowania, uznać za zbędne. W wersji 5 (tj. 1.5) dodano kilka kolejnych. Przykładem niech będzie instrukcja warunkowa (dostępna bodaj od początku), np.:

return yourAge() > 50 ? "An old man" : "A young person";

Z konstrukcji tej można by przecież było zrezygnować, a powyższy kod zastąpić kodem używającym konstrukcji warunku:

if( yourAge() > 50 )
return "An old man";
else
return "A young person";

Jestem ciekaw, jakie są opinie polskich programistów na ten temat. Jesteście "za a nawet przeciw"? Widzicie jeszcze jakieś kontrargumenty?

8 komentarzy:

bmalkow pisze...

Ja tam konstrukcję yourAge() > 50 ? "An old man" : "A young person" lubię, mimo że nie jest elegancka.

Mariusz Lipiński pisze...

Ja też lubie tę konstrukcję i polubił bym również import ... as ...

Michał Jonik pisze...

Dla prostych i krótkich porównań stosuje pierwszą konstrukcję. Jeżeli wyrażenie warunkowe jest bardziej złożone wówczas drugą, dłuższą.

Mariusz Lipiński pisze...

Michał,

a co myślisz o wprowadzeniu konstrukcji import ... as ...? Uważasz że było by z tego więcej pożytku czy szkody (niebezpieczeństw)?

Kuba pisze...

taki mechanizm istnieje już w c#.
jak dla mnie jednym z plusów javy jest jej wyważona liczba słów kluczowych, która mieści pomiędzy skrajnościami jakimi są poor ansi c (albo brainfuck;) a z drugiej strony bogatym c#.

Mariusz Lipiński pisze...

Dzięki za info, ja niestety nie mam pojęcia o .NET. Tym bardziej dzięki. Rozumiem, że twój głos jest na nie.

a5phyx pisze...

Konstrukcja ?: wywodzaca sie z C/C++ jest jedna z moich ulubionych :) Odnośnie pomysłu Kolegi, jestem przeciwny wprowadzaniu podobnego mechanizmu. Juz sobie wyobrazam jak co drugi koder, wprowadza swoje aliasy dla prawie kazdej klasy. Koszmar! Chyba, ze dodatkowo ograniczymy mozliwosc nadawania aliasow, tylko do klas o identycznych nazwach importowanych w danym zrodle - ale i tak mocno bym sie nad tym zastanowil. Jak tak dalej pojdzie, syntaktyka Javy rozrosnie sie za bardzo i w pewnym momencie bedzie takie same zamieszanie jak chociazby z przeciazaniem operatorow w C++ - ciezko czyta sie kod osob, ktore przeciazaja operatory gdzie to tylko mozliwe.

slawomir wojtasiak pisze...

Raczej też jestem przeciwny. Docelowo moglibyśmy się spotkać z problemami podobnymi do tych jakie powstają podczas analizy kodu osoby, która uważa ze preprocesor jest jedną z najlepszych cechą języka C, więc należy go stosować przy każdej nadarzającej się okazji ;). Wyobraźmy sobie kod, którego autor jest przyzwyczajony do C# i pozamienia sobie przykładowo klasy odpowiadające typom prostym na Int32, Int64 itd ;)