Programování v jazyce D: Úvod a první kroky (1)

1. 7. 2011 | Daniel Kolesa | Programování | 20995×

D je programovací jazyk, jehož záměrem bylo „C++ done right“, a tak jeho autoři kolem roku 1999 začali s kompletním redesignem jazyka C++ a odstraňováním jeho návrhových chyb. První stabilní specifikace se jazyk dočkal v roce 2007 a momentálně se pracuje na druhé verzi jazyka, o které bude i tento seriál.

Druhá verze je momentálně doporučovaná pro veškeré nové projekty, neobsahuje některé chyby předchozí verze a přidává spoustu nových možností – hodně lidí už nazývá D2 prostě "D". Seriál počítá s tím, že čtenář má alespoň základní znalosti programování a jazyka C, popř. C++.

Obsah

• Vznik, inspirace, použití
• Verze jazyka D, kompilátory
• Standardní knihovna
• Hello World v D
• Komentáře v D
• Typy a proměnné
• Výrazy, mixiny, podmínky, cykly
• Závěr

Vznik, inspirace, použití

Jazyk D se objevil v roce 1999 a jeho autorem je Walter Bright ze společnosti Digital Mars. Postupně vznikla menší komunita, ale jazyk stále není dost rozšířen, protože specifikace verze 2.0 není finální a kompilátory stále mají několik much.

Specifikačně, D je multi-paradigm, s podporou imperativního programování jako v C, objektového/generického/meta jako v C++, i funkcionálního a konkurentního. Hlavními zdroji inspirace jsou C, C++, Java, Python, Ruby, C# a Eiffel. I když je D high-level jazyk, podporuje i kompletně low-level přístup, včetně inline assembly.

D používá statické/silné typování a podporuje všechny Cčkové POD typy. Imperativní programování je velmi podobné Cčku, objektový systém přebírá z Javy (nemá vícenásobnou dědičnost, místo toho používá interfaces/mixins), modulový systém je podobný Pythonu. Kromě toho se inspiruje z velké části C++.

D je obecně použitelný a výkon výsledné binárky by měl být srovnatelný s Cčkem.

Kromě toho má D garbage collector, takže si programátor nemusí sám uvolňovat paměť (i když může a gc může být i kompletně vypnuto). Kromě toho je D kompatibilní s C ABI, takže se dá přímo linkovat proti knihovnám napsaným v C (definice prototypů se uzavírají v bloku extern(C)). Kvůli systému modulů nepodporuje D hlavičkové soubory a neobsahuje preprocesor, vše se dá dělat přímo v jazyce.

Verze jazyka D, kompilátory

Momentálně má D dvě verze, D1 (stabilní specifikace) a D2 (vývojová specifikace). Digital Mars doporučuje používat pro nové projekty D2, protože se poučilo z některých chyb D1 a není s D1 plně kompatibilní.

Kompilátorů je několik, hlavní jsou čtyři:

dmd – oficiální kompilátor od Digital Mars. Je vcelku malý (o dost menší než třeba gcc). Tvoří jej dvě části, backend a frontend. Nevýhoda je v proprietární licenci backendu (zdrojový kód je dostupný a je možné do něj přispívat, ale jeho licence nedovoluje redistribuci). Frontend je licencovaný pod GPL v2. Většina ostatních kompilátorů využívá DMD frontend. V době psaní článku měl dmd jednu nevýhodu, a to že neumí tvořit sdílené knihovny – nepracuje správně s PIC registrem.

gdc – využívá gcc backend a dmd frontend. Je to asi nejpoužitelnější D kompilátor, funguje i tvorba sdílených knihoven. Je aktualizován pokaždé, když vyjde nová verze DMD. Podporuje obě verze jazyka.

ldc – využívá llvm backend a dmd frontend. Verze pro D1 je dobře použitelná, verze pro D2 je ve vývoji a v době psaní článku neuměla část standardní knihovny jazyka.

sdc – D2 kompilátor napsaný v D. Je ve vývoji a zvládá jen několik testů.

Kromě toho ještě existoval D2/.NET komilátor kompilující do CLR bytekódu, ale projekt je momentálně neaktivní. Ve většině kompilátorů jsou podporovány všechny hlavní platformy. Seriál je psaný na FreeBSD x64.

Standardní knihovna

Standardní knihovna D se jmenuje Phobos a je dostupná pod Boost licencí. V D1 byla dost omezená a plná chyb, a tak vznikla knihovna Tango, která je dobře použitelná. Nakonec to vyústilo v to, že něco používalo Phobos a něco Tango a obě byly mezi sebou nekompatibilní.

V D2 se tohle vývojáři snažili řešit a vznikl Druntime, runtime knihovna pro D (též dostupná pod Boost licencí). Ta poskytuje ty úplně základní věci jako práci s vlákny, garbage collector apod. Pracuje se na portu Tango do D2, ale Phobos je už dobře použitelná knihovna. Tango i Phobos v D2 by měly být v budoucnu dobře kompatibilní díky druntime.

Seriál se bude zabývat knihovnou Phobos v D2. Oproti např. stdlib v C++ poskytuje Phobos velké množství funkcí, které jsou v C++ normálně doplňovány např. Boostem (JSON parser, kryptografie, curl, threads, URL, XML parser a další).

Hello World v D

Naprostá většina seriálů o programování začíná slavným „hello world“ a já budu konzervativní a výjimku neudělám Zápis je velmi podobný Cčku/C++.

/* program vypíše "hello world!" do konzole */

import std.stdio;

void main()
{
    writeln("hello world!");
}
        

Tento kousek kódu ukazuje hned několik vlastností jazyka. Klíčkové slovo import slouží k načtení modulů (o modulech budu psát v pozdějších dílech seriálu). V našem případě importujeme modul std.stdio, což je I/O část standardní knihovny Phobos.

Veškeré programy psané v D obsahují funkci main, stejně jako v Cčku. Tato funkce je zavolána když program spustíme. Oproti C, main může být i typu void, v tom případě vrací program vždy nulu. Stejně jako v C ale může být typu int a vracet hodnoty. Kromě toho může brát argumenty int argc, string[] argv, kde stejně jako v C argc je počet argumentů a argv je pole s argumenty (včetně nultého argumentu!). V našem případě z main voláme funkci writeln, která vypistuje neformátovaný text zakončený \n. Knihovna samozřejmě obsahuje i spoustu jiných I/O funkcí, ale o těch později.

Komentáře v D

Ty jsou identické s C99/C++ s přídavkem vnořených komentářů. // je jednoduchý řádkový komentář, /* */ je blokový komentář a kromě toho umí i vnořené blokové komentáře pomocí /+ /+ +/ +/.

Příklady:

// řádkový komentář

/*
 * část blokového komentáře
 */

/+
 + komentáře s vnořováním
 /+
  + vnořený komentář
  +/
 +/
        

Typy a proměnné

V tomto je D velmi podobné C/C++. Obsahuje všechny C(++) POD typy plus několik svých. Některá klíčová slova ale chybí, některá jsou nová a kromě toho jsou zde i nové typy a některé stávající mají trochu rozdílné chování. Začneme s těmi základními.

bool mybool; // má automaticky hodnotu "false"
mybool = true;
mybool = 1; // stejné jako true
mybool = 0; // stejné jako false

int myint; // hodnota 0
myint = 150;
myint = int.max; // maximální hodnota

/* v D neexistuje klíčové slovo "unsigned", místo toho mají unsigned
typy prefix "u" */
uint myuint; // 0
// myuint = -1 // nejde!
myuint = uint.min; // teď je hodnota 0

short myshort = 100;
long mylong   = myshort;

byte b = 0xF; // 15
ubyte ub = 255; // maximální hodnota

float f; // hodnota float.nan
f = 3.14;

/* přetypování */
int casted = cast(int) f; // ořeže hodnotu když je třeba

double dbl = f * 2;

/* typ real v D je desetinné číslo s největším rozsahem povoleným
hardwarem */
real r = 11111111111111.156;

/* imaginární členy komplexních čísel */
ifloat if; // hodnota float.nan + i
idouble id;
ireal ir;

/* komplexní čísla */
cdouble cd = 2 + 16i;
cfloat cf = cast(cfloat) cd; // ořeže hodnotu pokud je třeba

char ch; // unsigned UTF-8 znak, hodnota 0xFF
ch = 'f';

wchar wch; // unsigned UTF-16, hodnota 0xFFFF
dchar dch; // unsigned UTF-32, hodnota 0x0000FFFF

/* řetězce jsou de facto pole znaků jako v C – více v kapitole o řetězcích a polích */
string str = "hello"; // jako const char* v C
immutable(char)[] str2 = "world"; // alternativní zápis pro string
char[] str3 = ("mutable hello").dup; // možno měnit, jako char* v C
char[] str_mutable = str.dup; // jako strdup() v C

/* pole */
int[] arr = [ 5, 10, 15 ];
assert(arr.length == 3);

arr.length = 4; // takové pole je možno rozšířit
arr[3] = 20;

int[3] arr; // statické pole
int[] arr = new int[](10); // dynamické pole s předalokovanou velikostí

/* asociativní pole – hashtable */
int[string] harr = [ "foo":5 ];
harr["bar"] = 10;
        

Tento kus kódu ukazuje několik dalších vlastností jazyka. V dalších kapitolách se jimi budeme zabývat podrobněji (např. poli).

Výrazy, mixiny, podmínky, cykly

Výrazy v D se zapisují opět podobně jako v C(++). Jsou dostupné všechny standardní operátory: jak aritmetické, tak bitové i podmínkové. Nejlépě to objasní pár příkladů:

int foo = bar;
foo += 5; // přičte 5
foo -= 5; // původní hodnota foo
foo *= 2; // dvojitá hodnota foo
foo /= 2; // zpět na původní hodnotě
foo |= 2; // bitové OR
foo <<= 2; // levý shift

/* inline podmínky */
foo = (bar == 5) ? 10 : 15;

/* pokud se vyhodnotí jako false, ukončí program */
assert(foo == 10, "chybová zpráva");

/* AND, OR */
assert(foo == 15 && bar != 20 || meh == bah);

/* bitové výrazy */
x = y | 5; // OR
y = x & 5; // AND
z = y ^ x; // XOR

/* komplexní čísla */
assert(cx == cy); // stejné jako assert(cx.re == cy.re && cx.im
== cy.im);

/* null se používá s objekty */
class C;
C c;
assert(c == null); // neplatné, porovnává se obsah, null žádný nemá
assert(c is null); // správně
        

Všechny operátory je možné přetěžovat, více v kapitole o třídách. D podporuje také mixins. Používají se takto:

assert(mixin("5 + 10") * 2 == 30);

To se hodí např. při preprocesingu, když má programátor nějakou šablonu, kterou potřebuje zakompilovat do binárky. Více v kapitole o modulech a importu.

Zápis podmínek, cyklů apod. je standardní:

if (x == 10 && y == 5)
{
    /* true */
}
else if (y == 15 && x == 20)
{
    /* true */
}
else
{
    /* false */
}

for (int i = 5; i < 10; i++)
{
    dofoo();
}

while (i < 10)
{
    i++;
}

do
{
    bar();
} while (x == 10)
        

Rozdíl je trochu v použití switch. Oproti C a C++ je možné použít stringy u case:

string a = "hello";
switch (a)
{
    case "hello": break;
    case "world": break;
    default: break;
}
        

Kromě toho má D i foreach:

char[] mystr;

foreach(int idx, char ch; mystr)
{
    writefln("mystr[%d] = '%c'", idx, ch);
}

int[string] myharr;

foreach(string key, int value; myharr)
{
    ...
}
        

Výjimky jsou též podporovány:

try
{
    try
    {
        throw new Exception("first");
    }
    finally
    {
        throw new Exception("second");
    }
}
catch (Exception e)
{
    writefln("Caught %s", e.msg);
}
        

Kromě toho fungují i break, continue, goto a další z C.

Závěr

Tímto bych asi ukončil první díl seriálu. V dalším díle se budu zabývat funkcemi, poli, řetězci, popř. objekty. Na této stránce je mnoho dalších užitečných informací o jazyce, včetně kompletní dokumentace ke knihovně Phobos, takže je to určitě dobrý cíl dalšího studia. Tento seriál není kompletním  „návodem“ jazyce, ale spíš takovou pomocí, jak se v D zorientovat a jak s ním pracovat.

       

Komentáře

[kralyk z abclinuxu]

Dík za pěknej článek. Vždycky jsem po D nebo případně Obj-C pokukoval, tak mě to možná nakopne napsat něco příště v D Imho pro člověka zvyklýho na C++ by to mělo být celkem intuitivní až na pár detailů...

[tomboytom-deviant]

Obj-C ? Takze bude KERNEL-ULTRAS applikace pro iPhone?

[kralyk z abclinuxu]

Ode mě asi ne, já bych spíš šel do teho D...

[w4rr10r]

Taky se mi líbí (už dlouho), ale kvůli Qt a pár dalším věcem bych se radši držel C++.

[kralyk z abclinuxu]

QtD

[w4rr10r]

Ono je to trošku starší, vidím tam 4.4 a 4.6.

[kralyk z abclinuxu]

Hm, škoda... :/

[----]

v hg se celkem updatuje .. http://hg.dsource.org/projects/qtd/file/b2a803c73b89/ myslím, že bude novější

[kralyk z abclinuxu]

Vypadá to na 4.5.2 :/

[----]

No, celkem jo I když rozdíly tam jsou.

[pavlix]

D je programovací jazyk, jehož záměrem bylo „C++ done right“

To mi připomíná Subversion („CVS done right.“)...

[JoHnY2]

To vazne neni moc pochvalny prirovnani .

[pavlix]

Za to já ale nemůžu, já jsem nepsal „C++ done right“ :D.

[----]

No, s tím subversion je to de facto pravda ;)

[pavlix]

Tak to teda potěš koště.

[----]

SVN je opravdu o dost lepší než CVS, nicméně na git nemá

[Mrkva]

Komplexní čísla jako primitivní typy? Áááááááááááááááááááááááááá!

[Ondrej 'SanTiago' Zajicek]

Komplexni cisla jako primitivni typy ma i jazyk C.

[koudy]

Prosim? Nechci vyvoalavat flame, ale mohl byste uvest priklad? Treba jsem to jen spatne pochopil..

[Ondrej 'SanTiago' Zajicek]

Podpora komplexnich cisel je specifikovana v C99, priklad treba:

#include <stdio.h>
#include <complex.h>

int main(void)
{
  double complex a = 2+3*I;
  double complex b = 1-2*I;
  double complex c = a * b;
  printf("%f %f\n", creal(c), cimag(c));
  return 0;
}

[koudy]

Nojo my co se placame v ANSI C...

Dekuju za rozsireni meho obzoru :)

Vedel jsem ze v c++ to je jako class, ale myslel jsem si ze c nic takoveho nema.

[LangPa]

a co treba kvaterniony? To by se 3D psalo samo

[blazzter]

clovek konecne zostatnicuje z fyziky a tu mu zacne niekto pripominat cim v prvaku v algebre zacinal :/

[jnml]

Komplexní čísla (64/128bit) má zabudované také Go.

[vladaf]

Něco se vám nelíbí na vlastnosti, kterou měl Fortran už na konci PADESÁTÝCH let?

[Honza]

zajímavé, mrknu na to. já bych jen doplnil, že interfaces používá i C# a to má nejen Garbage Collector, ale i přímý přístup do paměti jako C++. co tomu chybí tak multiplatformnost, ale to je jen dobře pro Javu

[vain]

No pokud si jak se patří správný sadomasochista, můžeš brát jako multiplatformnost C# Mono

[Radek Miček]

Pokud se vyhnete nepodporovaným funkcím, není problém napsat aplikaci, která poběží v Monu i v .NET Frameworku.

[vain]

To je sice hezké, ale pořád mi to přijde multiplatformní asi jako pouštět hru pro Windows ve Wine.

[Radek Miček]

Nerozumím, jak to myslíte, můžete to prosím trochu rozvést.

[pavlix]

To je sice hezké, ale pořád mi to přijde multiplatformní asi jako pouštět hru pro Windows ve Wine.

Což vzhledem ke věcem jako je winelib, nebo i obyčejnému zapouzdření wine do skriptu, není vůbec špatné. Ovšem pokud ta hra bude psána jako multiplatformní (což nevylučuje, že jednou z cílových platforem jsou windows).

[sidik]

If Java had true garbage collection, most programs would delete themselves upon execution.

;)

[koudy]

Tak tenhle je dobrej :D

[karel.k001]

Dík za hezkej článek! Chci se jen zeptat: K čemu jsou dobrý vnořený komentáře? Takovou věc vidím poprvé a nějak nemůžu přijít na to k čemu by se to mohlo hodit.

[w4rr10r]

Třeba když chceš zakomentovat blok kódu, aby se zrovna neprováděl, ale máš v něm nějaké normální komentáře?

[Roger]

Třeba když chcete na chvíli zakomentovat kus kódu, který už komentáře obsahuje. Teď se to musí dělat přes preprocesor (nebo aspoň já to tak dělám, rád se nechám poučit zkušenějšími zakomentovávači :) ).

[koudy]

Myslite: #if 0 . . . #endif

Taky to pouzivam a prijde mi to jako docela sikovny zpusob..

[Sten]

To je samozřejmě šikovný způsob pro C a C++. D preprocesor nemá, tak vymysleli tohle.

[kralyk z abclinuxu]

Šikovný to třeba je, ale návrhově čistý teda ne...

[----]

a má to ještě jeden problém - je to horší detekovat jako komentář než normální značky pro komentáře, takže většina editorů tohle nezahrnuje do zvýraznění syntaxe a tím pádem je občas složitější zjistit, co je zakomentovaný a co ne.

[Sten]

Když si editory poradily s begin a end v Pascalu, tak komentáře už zvládnou. Nehledě na to, že problém nejsou samotné znaky, ale to, že ty komentáře mohou být rekurzivní — což je ale stejný problém i pro D.

[kralyk z abclinuxu]

No tak většina editorů zvýrazňuje C-makra. Vyhodnocuje je, a a když podmínka neplatí, příslušnou část zašedí (apod.). Takže v tom by problém být neměl...

[----]

Neřekl bych většina .. některé asi jo, ale většina editorů s podporou pro velké množství jazyků makra nevyhodnocuje. Akorát umožňují expand/collapse.

[pavlix]

Ač krályk napsal většina... myslím, že je to úplně jedno. Stačí aby to uměl ten, který používáš :) (nebo abys používal, ten který to umíš, což znamená to samé, ale trošku víc napovídá, jak si s tím poradit).

Myšleno obecně, ne pro tuto jednu vlastnost (kterou nepoužívám, protože mi komentáře stačí)

[----]

no, já momentálně používám Geany, který umí spoustu věcí, ale zrovna to #if 0 ne.

[Sten]

Návrhově čistý to sice není, ale tyhle komentáře by se stejně většinou neměly objevit v repozitáři, protože označují dočasnou úpravu při ladění.

[Atom321]

K zakomentování kusu kódu který má v sobě komentáře.

[Ladicek]

V jazyce, který má komentáře od tokenu (//) do konce řádku (a to D má), absolutně k ničemu.

[dad]

je zvlastni, ze se tohodle vaseho komentare nikdo nechyt. Pritom si myslim, ze je to jeden z nejpodstatnejsich prispevku tady.

[JS]

Neni, co kdyz chci zakomentovat blok, co konci v pulce radky? :-P

[LangPa]

tak tomu se říká prasárna

[Ladicek]

A zrovna jako na potvoru je tam komentář, co?

[Bystroushaak]

Díky tomu je možné zakomentovávat i komentáře. Slouží to hlavně rychlým úpravám kódu:

/* Začátek komentáře

/* Předchozí komentář
*/ Konec předchozího komentáře, který ukončí blok komentářů

*/ Zamýšlený konec komentáře, ve skutečnosti chyba

vs

/+ Začátek komentáře

/* Předchozí komentář
*/

+/ Konec komentáře

BTW: Autor ještě zapomněl zmínit dokumentační komentáře.

[----]

Vzhledem k tomu, že D nemá preprocesor, tzn. žádný #if 0, používají se pro zakomentování kódu s komentáři.

[Radovan Garabík]

char ch; // unsigned UTF-8 znak, hodnota 0xFF

UTF-8 znak (čo to vlastne je?) asi nemôže mať hodnotu 0xFF...

[me]

Ano, tato konstrukce by si rozhodne zaslouzila vysvetleni, protoze me take sokovala...

[Bystroushaak]

Může.

import std.stdio;

void main(){
    char ch;
    writefln("0x%x", ch);
}

bystrousak@kitakitsune:~/Plocha$ rdmd char_test.d
0xff

Několik dalších informací třeba v oficiální dokumentaci: Types, Porovnání C++ a D stringů.

[----]

může:

http://ideone.com/NGbmt

http://www.eki.ee/letter/chardata.cgi?ucode=00FF

http://www.utf8-chartable.de/

[Sten]

Díval jste se na ten odkaz (hlavně ten druhý)? Je tam jasně napsáno: UTF-8 (c3, bf). V UTF-8 nemá bajt 0xFF co dělat.

[me]

Asi se mysli U00FF.

[pavlix]

Tak to asi nemá s kódováním moc společného, vzhledem k tomu, že Unicode rozlišuje znakovou sadu a kódování... ale to už bysme zabředávali do filosofických debat :).

[Sten]

Není to UTF-8 znak, ale bajt. V D se to většinou používá pro UTF-8 řetězce, ale nijak se to nevynucuje ani nekontroluje (asi jako C++ string nekontroluje, co je uvnitř). Ta hodnota je samozřejmě schválně zvolená tak, aby to platný UTF-8 znak (či část znaku) nebyl.

[pavlix]

Tak to asi chtělo lepší vysvětlení v kódu.

[kralyk z abclinuxu]

No, s těma utf-8 a utf-16 to je v kódu dost mimo, ani jedno není fixed-width kódování...

[pavlix]

A až dojde IPv6, tak už dávno nebude fixní ani utf-32.

[alblaho]

assert(mixin("5 + 10") * 2 == 30);

WTH? Tady mixiny jsou asi něco jiného než třeba v Ruby, ne? Já bych to pojmenoval "eval" .

[Bystroushaak]

Funguje to podobně jako eval, až na to že se to vykoná před kompilací, nikoliv ve zkompilovaném programu. Díky tomu (a statickému if) je možné nepoužívat makra s jinou syntaxí než zbytek jazyka.

[----]

V D se rozlišují dva typy mixins, string mixins (něco jako eval) a template mixins. Obojí jsou popsány dokumentací jazyka. :)

[Tomáš]

Autor my mohl trochu rozebrat otázku: "Proč používat D?".

V článku je napsáno, že jazyk D se inspiroval snad vším od C až Javu, tak by mě zajímalo, jaké je vlastně jeho místo. C/C++ jsou kompilované jazyky, v dnešní době považované za "nízkoúrovňové", naproti tomu stojí třeba Python nebo Java, které potřebují ke spuštění interpretr. Pak tu máme Objective-C, které je taky kompilované, ale programátor v něm má mnohem větší pohodlí, než třeba v C++. Kam by autor zařadil jazyk D a proč ho používat?

[w4rr10r]

IMHO je to něco jako Vala nebo Objective C, takže je to pohodlnější než C++, ale ne (o moc) pomalejší. Průšvih je, že nejsou-li knihovny, není moc využití.

[----]

D je systémový programovací jazyk, který je na tom výkonově podobně, jako Cčko nebo C++, a přitom dává programátorovi high-level pohodlí, jako třeba Java a C#. Je v podstatě navržen jako C++ bez různých designových chyb a je tvořen pro praktičnost, tzn. neháže programátorovi klacky pod nohy a místo toho se snaží spoustu věcí řešit za něj (jako např. správu paměti). Ale je jen na programátorovi, jestli chce funkcí jazyka využít, nebo si radši bude dělat vše sám :)

[petr_p]

Autor poukazuje na linkovatelnost k objekovým souborům jiného kódu, ale zároveň dodává, že prototypy je nutné obalit do bloku extern C. To ovšem znamená, že se překladač používá pro symboly v objektu jiné názvy, než které používá programátor v D.

Táži se tudíž, jestli specificikace stanovuje name space mangling, nebo jestli to je ponecháno na libovůli překladače, jako to je u C++, pročež není možné míchat knihovny přeložené různými překladači (nebo dokonce jejich verzemi)?

[----]

ano, D mangling specifikuje (přímo v knihovně)

[olgo]

Je dobre, že sa niekto podujal písať o D česky.

Popri foreach by som určite spomenul i foreach_reverse a mixiny by som ponechal na samostatný diel.

V poslednom príklade sú špatné úvodzovky:

throw new Exception(„second“);

Dík za seriál.

[long long unsigned int]

To by mě zajímalo, jaké designové nedostatky D z C++ odstranilo. V uvedených příkladech nic moc nevidím...

[----]

Kontejnery v jazyce, stringy v jazyce, lepší metaprogramming, lepší streamy, formátování stringů, kompletnější knihovna, lepší operator overloading, sourodý exceptions, garbage collection (žádný polovičatý smart pointery), ...

[long long unsigned int]

Z vaše výčtu v příkladech vidím jenom kontejnery přímo v jazyce, tady konkrétně hashtable, což považuji naopak za významné pokurvení jazyka, a lehkou zmínku o GC, který, když už teda na něm někdo trvá, lze mít v C++ také (ne, o smart_ptr nemluvím).

Ale třeba to bude v dalších dílech lepší.

[----]

no, ono lze mít gc v C++ také, ale moc se to nepoužívá, protože to může kolidovat s různými knihovnami, není to standardizované; V D je gc přímo součástí runtime. jinak tento článek nemá ani moc porovnávat s C++, ale spíš sloužit jako takový úvod do jazyka, ty rozdíly od C++ budou vidět více v dalších dílech, jak budu popisovat různé pokročilé featury .. a IMO, kontejnery v jazyce jsou lepší přístup, ale to je asi věc osobního vkusu

[Michal Kubeček]

IMO, kontejnery v jazyce jsou lepší přístup, ale to je asi věc osobního vkusu

Pro jednodušší programy je to samozřejmě výhoda, syntaxe je přehlednější, pohodlnější a názornější. Ale časem se dostanete do situace, kdy budete potřebovat nějaký kontejner, který v jazyce není. A pak se nutně ty ručně dopsané budou syntaxí lišit od těch standardních. Výhoda kontejnerů ve standardní C++ knihovně je, že si můžu napsat vlastní rb_map, který interně používá RB strom, ale navenek se chová stejně jako standardní std::map, takže v případě potřeby stačí vyměnit typ v deklaraci, přidat jeden #include a na kódu nemusím měnit vůbec nic.

[pavlix]

Ono se stačí podívat, jak to má třeba Python (a částečně i C++). Pro kontejnery jsou připravené standardní metody a operátory a stačí je jen definovat. Python má k tomu standardní kontejnery v jazyce, ale není problém udělat si alternativní implementaci a používat ji na 99% stejně (jen inicializace vyžaduje trochu syntakticky pocukrovat :)).

[Šangala]

nemá vícenásobnou dědičnost - ach jo, C++ nenahradí

[----]

proč ne? Multiple inheritance je zlo A navíc funkčně to můžeš emulovat pomocí interfaces / mixins.

[kralyk z abclinuxu]

No tak interfaces je de-facto podmnožina vícenásobné dědičnosti (takže nedovolí některé prasárny, ale zas někomu to může připadat omezující...).

[pavlix]

Mně připadá omezující tím správným směrem. Vícenásobná dědičnost ve statickém jazyce je vždycky docela prasárna.

[Luboš Doležel (Doli)]

To bych neřekl. Pokud bychom měli interface Animal, tak v C++ můžu udělat class DefaultAnimal, které bude mít některé metody naimplementované (abstraktiní třída). Pak můžu mít velkou třídu, která bude dědit po několika takových abstraktních třídách.

V C++ to půjde, v Javě ne. A přitom v podstatě jde pořád jen o vícenásobnou dědičnost v podobě rozhraní, akorát si ale ulehčuju práci pomocí nějakých výchozích implementací.

[Šangala]

To je přesně to, „vo co go“ .

[Luboš Doležel (Doli)]

Aha, koukám, že jste o kousek níž psal to samé

[Šangala]

Jo, ale nedokázal jsem se jasně vymáčknout

[Sten]

Možná pomocí mixinů, otázka je, jak čistý ten zápis bude. Rozhraní neumožňují vícenásobnou dědičnost s proměnnými, zatímco vícenásobnou dědičností lze rozhraní velmi jednoduše emulovat.

[pavlix]

Interfaces mají něco do sebe.

[Šangala]

Mají a jsou super, nicméně vícenásobná dědičnost není zlo, ale umožňuje někdy výrazně méně psaní, když to je potřeba.
Veřejné rozhraní by asi (já si tím nejsem jistý, podléhám tlaku ) mělo být řešeno přes interface. Ale nerad píšu interface pak funkční class-y a jednu/dvě/tři vnitřní implementace, které budou vždy totožné, můžu neustále kopírovat (to je blbost), nebo napíšu další třeba i „statickou“ třídu. Raději udělám „abstraktní“ objekt místo interface a totožnou funkcionalitu implementuji tam kam patří - v něm .
Prostě nežeru myšlenku: „Interface nesmí nikdy obsahovat nějakou implementaci“.

[pavlix]

Mají a jsou super, nicméně vícenásobná dědičnost není zlo, ale umožňuje někdy výrazně méně psaní, když to je potřeba.

Nevšiml jsem si.

Prostě nežeru myšlenku: „Interface nesmí nikdy obsahovat nějakou implementaci“.

Tak to se shodnem. Já neměl namysli nutně pouze abstraktní interface. Ale ve většině případů s ním vystačím. Při dobrém návrhu se dá funkcionalita interface vyhodit do samostatné třídy, takže i absence implementace se dá obejít.

Přijde mi to jako menší prasárna než řešit při vícenásobné dědičnosti problémy s vícenásobným předkem.

[Šangala]

Pokud se bavíme o tom, že interface má nějakou implementaci, tak to už není interface ve smyslu, že lze vícenásobně zdědit/implementovat pokud není povolená vícenásobná dědičnost.
Pokud implementaci vyhodím do další třídy, tak je to právě to psaní navíc jen abych dostál nemožnosti vícenásobné dědičnost, ale principiálně je to „workaround“ a způsobí právě to, že se více píše. A jiném případě se zas musí zapouzdřovat a zveřejňovat a zas je to více psaní (zapouzdření není vždy ten správný přístup, i když bezpečný).
Pokud se použije nějaká názvová konvence a používá se to „přímo“ ve „finální“ třídě, obvykle žádné problémy nenastanou, a efektivita je vyšší a čitelnost či přehlednost to neovlivní.
Si prostě myslím, že vícenásobná dědičnost není zlo, zlo je když se používá místo „interface“ a její odstranění považuji za zbytečnou obstrukci jazyka.

[Ladicek]

IMHO odstranění vícenásobné dědičnosti je jen první krok směrem k nevyhnutelnému odstranění jakékoli dědičnosti, protože to je evidentně mizerný způsob sdílení implementace. Chtělo by to jazykovou podporu pro delegaci, ale to bohužel zatím nikdo nemá (nebo o tom nevím; akorát v Noop to nějak zvažovali, ale ten projekt je AFAIK mrtvý). Jako alternativu vidím traity (nemyslím ty scalovské, to jsou ve skutečnosti mixiny), ale to si budu muset ještě líp promyslet.

[kralyk z abclinuxu]

Chtělo by to jazykovou podporu pro delegaci

To by imho bylo dědičnosti velice podobné (onehdá se o tom vedl flejm). Byla by to vlastně dědičnost, akorát s trochu jinými pravidly přístupu.

[Ladicek]

Ne. Fatálním problémem dědičnosti je těsná vazba, to u delegace odpadá. Delegáta můžeš za běhu vyměnit atd.

[kralyk z abclinuxu]

No jasný no, větší kontrola nad "rodičem". Však já neříkal, že ne

[Radek Miček]

Chtělo by to jazykovou podporu pro delegaci, ale to bohužel zatím nikdo nemá

Nevím přesně jakou formu podpory máte na mysli, ale některé jazyky dovolují rozšiřovat syntax, takže by neměl být problém si tu podporu dodělat.

[pavlix]

IMHO odstranění vícenásobné dědičnosti je jen první krok směrem k nevyhnutelnému odstranění jakékoli dědičnosti,

IMHO vyvráceno praxí.

[Ladicek]

Samotný výraz vyvráceno praxí je nesmysl.

[pavlix]

To samé si myslím o tvém tvrzení, na které jsem reagoval.

[Ladicek]

No tak to seš celej úchvatnej Jsou to právě praktici, kdo zjistili, že dědičnost je mizerný způsob sdílení implementace a že by se jí programátor měl pokud možno vyhýbat.

[pavlix]

Já nevím, co chceš řešit na tvém nesmyslném tvrzení, že odstranění vícenásobné dědičnosti vede nevyhnutelně na odstranění dědičnosti jako takové. Radši jsem ti na to měl napsat: „Proč lžeš?“ :D

[podlesh]

Ale on napsal něco úplně jiného: on napsal, že je to jen první krok

[pavlix]

On použil slovo nevyhnultené, tedy že se tomu druhému kroku nelze vyhnout.

[Ladicek]

Proč lžeš?

Jo, tvrdím, že odstranění dědičnosti je nevyhnutelné, přináší prostě příliš mnoho problémů. Neřekl jsem, že odstranění vícenásobné dědičnosti vede nevyhnutelně na odstranění jednoduché, ale že to je IMHO první krok. Je ten významový rozdíl tak malý?

Z teoretického i praktického pohledu je vícenásobná dědičnost jen triviálním rozšířením té jednoduché, které přináší výrazně míň problémů, teoretických i praktických, než zavedení dědičnosti vůbec. Jsou nějaké problémy, které dědičnost docela dobře řeší (já vím teda o jednom, GUI toolkity a hierarchie widgetů), ale IMHO ten přínos zdaleka nevyvažuje zápory.

[alblaho]

Láďo, to tvoje odsouzení dědičnosti je docela zajímavé. Ale mám jen mlhavou představu, jak by měla vypadat ta tvoje delegace. Nechceš napsat nějaký framework pro delegation-oriented-programming v nějakém dostatečně ohebném jazyce (Ruby, Python) a pak to publikovat?

To by bylo jen run-time. Pak bys forkl Scalu, skoro všechno z ní vyházel a udělal díru do světa.

V práci mám kus kódu zralý na refaktoring: je to hierarchie různých parserů pro síťové protokoly (pro IP kamery, RTSP, HTTP atd.). A je dost dobře možné, že OOP zrovna pro tohle není to pravé ořechové.

[Ladicek]

No, představ si asi tohle:

class A {
  B b expose *; // řekněme, že B má metody m1 a m2
  C c expose m3, m4;
  D d expose * but m5, m6; // řekněme, že D má metody m5, m6 a m7
}

Triviální desugaring vypadá takhle:

class A {
  B b;
  C c;
  D d;

  m1() { b.m1(); }
  m2() { b.m2(); }
  m3() { c.m3(); }
  m4() { c.m4(); }
  m7() { d.m7(); }
}

Snaha vystavit metodu se stejnou signaturou z víc delegátů by vedla k chybě při překladu. Má to pár zajímavých sémantických problémů: Kdy se inicializují b, c a d? Smí se za běhu změnit? A vynullovat? Jak by se ta změna projevila v ostatních vláknech?

Jedna věc, která se mi líbí na traitech, kterou takovýmihle triviálními delegáty neuděláš: Trait smí deklarovat abstraktní metodu, kterou musí "implementující" třída definovat. Takže je tam ta vazba vlastně obousměrná. Je to užitečné, ale nejsem si jistý, jestli to nemá nějaké vlastní problémy.

Další související věc by byla jazyková podpora pro dependency injection

[alblaho]

Nejsem zrovna kovaný v abstraktních úvahách o tom, jak zkonstruovat typový systém (možná níže kecám kraviny), ale pocitově se mi tvoje DOP docela líbí.

Pokud bych si to představil v intencích Javy, tak mi to přijde ohromně jednoduché, vždyť je to opravdu jenom syntaktický cukr, abys nemusel psát ty obalovací metody. Aby se s tím dalo pracovat, tak by to ještě chtělo taková ta implicitní rozhraní, co má Go: třída A podporuje taková rozhraní, pro něž jsou všechny potřebné metody vystavené.

Jestli se můžou vnitřní třídy měnit a nullovat za běhu závisí jenom na tom, jestli preferuješ záruky od překladače nebo pružnější chování za běhu.

A k těm abstraktním metodám z traitů, v čem je problém? V intencích Javy:

class A {
  B b = new B() exposing *; // řekněme, že B má metody m1 a m2
  C c = new C() exposing m3, m4 {
      public int m4 {
          // implementing abstract method
          return 42;
      }
  }
}

Aby to bylo konzistentní, tak by metoda m4 asi neměla vidět nic ze symbolů v A. Jenže to právě ty mixed-in metody v Ruby dělají, což? Případně by m4 mohla definovat obalovací třída A, hmmm, máš pravdu, je to zajímavý problém.

[Ladicek]

Ono to není žádné DOP, to je normální OOP, jen bez dědičnosti.

Aby se s tím dalo pracovat, tak by to ještě chtělo taková ta implicitní rozhraní, co má Go: třída A podporuje taková rozhraní, pro něž jsou všechny potřebné metody vystavené.

Jasně. Existuje totiž jeden rozdíl, o kterém už jsem na ábíčku několikrát mluvil, ale spousta lidí si ho pořád neuvědomuje, rozdíl mezi podtypem a podtřídou. Zdálo by se, že v mém příkladu výše bych nemohl napsat B b = new A(), protože A přece není podtřídou B. To sice není, ale je jejím podtypem (viz substituční princip Báry Liskovové). To lze zjistit automaticky, jako v tom Go, nebo lze vyžadovat, aby to programátor deklaroval. Nemám vyhraněný názor na to, co je správné.

A k těm abstraktním metodám z traitů, v čem je problém?

Já to asi řekl špatně. Traity umožňují něco takového:

trait T {
  abstract int m1(); // jenom třída, která má m1, může includovat T

  int m2() {
    return 2 * m1();
  }
}

class X with T { // to je OK
  int m1() {
    return 1;
  }
}

class Y with T { // to je chyba při překladu, Y nemá m1
}

Je to taková rozumnější forma dědičnosti, která netrpí některými problémy (narozdíl od mixinů). Ale máš pravdu, mohli bychom uvažovat abstraktní třídy bez dědičnosti, a ve třídě, která by na někoho takového chtěla delegovat, bychom ty abstraktní metody museli dodefinovat. Ta dodefinovaná metoda by naopak měla přístup k vnějším symbolům, a měli bychom to kompletní.

To možná není špatný nápad. Delegát může mít svůj stav (trait ne; mixin ano, ale ten stav se dědí, zatímco tady by byl zapouzdřený), to je užitečné, vystavit z něj jde jenom metody, kolize je třeba řešit ručně, to by mohlo fungovat.

[kralyk z abclinuxu]

Celkově ten tvůj koncept vypadá docela pěkně (imho stále jiný druh dědičnosti ), eště by to chtělo vymyslet konstruktory, ale to by neměl být takový problém.

Vyměňování za běhu by taky neměl být problém, s tím, že typová kompatibilita by se kontrolovala při compile-time.

[Ladicek]

No, jestli považuješ agregaci za jiný druh dědičnosti, tak samozřejmě. Zrovna tak můžeš považovat dědičnost za jiný druh agregace. Já v tom vidím významné rozdíly. Mimochodem, hodně přemýšlení tomu věnovali chlapci kolem projektu Noop: http://code.google.com/p/noop/, ohledně dědičnosti a kompozice konkrétně tady: http://code.google.com/p/noop/wiki/ProposalForComposition.

Konstruktory jsou průšvih, ty je taky třeba zrušit Tedy aspoň v současné podobě běžné v C++/Javě/C#, kde volající rozhoduje o tom, jaká třída se vlastně bude instancovat, o tom by měl rozhodovat volaný.

[kralyk z abclinuxu]

No, jestli považuješ agregaci za jiný druh dědičnosti, tak samozřejmě. Zrovna tak můžeš považovat dědičnost za jiný druh agregace.

No já tadyto žonglování s těmihle pojmy celkově moc nemusím... mně to přijde jako buzzwordy. Ono totiž v praxi je "dědičnost" něco jinýho v C++, něco jinýho v Javě a něco jinýho v C# a tak dále. Každá z těhle implementací má svoje problémy, a tím pádem i svoje (různá) řešení.

No a pak říkat, že "Návrhový vzor X bych nahradil Y" je takové mnhoznačné, protože v každým jazyce/prostředí by to způsobylo něco jinýho...

o tom by měl rozhodovat volaný

Kvůli tomu přece není potřeba rušit konstruktory. Nějakou formu kontruktoru mít musíš...

[Ladicek]

Buzzwordy, hmm, a co že toho nejsou plná všechna ta byznys-oryentyd mídia typu ITBiz? OOP byl buzzword, někdy před 20 lety, dneska letí NoSQL, ale dědičnost a agregace? Pojmy mají i svůj význam, proto existují, a že se ti zrovna nechce… no, to není můj problém.

Konstrukce objektu je hrozně magická operace. Já bych se bez ní nejradši obešel úplně (hezky to mají vyřešené v prototypových jazycích, kde spadne shůry jen jeden objekt a všechny ostatní už jsou jenom kopie, protože kopie, tomu rozumím), ale nevím jak. Přemýšlel jsem o speciálním druhu třídy, factory, která by jediná mohla používat operátor new, ale to v zásadě nic neřeší a jenom to přidělává bordel. Dependency injection je výborná věc, ale jen na určitou množinu problémů, univerzální řešení to není. Fakt nevím.

[kralyk z abclinuxu]

Buzzwordy, hmm, a co že toho nejsou plná všechna ta byznys-oryentyd mídia typu ITBiz? OOP byl buzzword, někdy před 20 lety, dneska letí NoSQL, ale dědičnost a agregace? Pojmy mají i svůj význam, proto existují, a že se ti zrovna nechce… no, to není můj problém.

Ty pojmy mají svůj význam, ale jen v nějakém konkrétním kontextu. Ne ve filosofické debatě typu "Dědičnost je špatná, měla by se nahradit delegací/agregací/perforací/jánevimčim". Měla by se nahradit v jakém projektu? V linux kernelu? V GUI toolkitu? Ve webovém frameworku? A podobně...

Prostě říct, že návrhový vzor X je lepší je jako říct, že operační systém X je lepší. Bez bližšího kontextu to nemá valný smysl.

Konstrukce objektu je hrozně magická operace.

Houby magická operace Je to jen alokace paměti a její inicializace. O co v tomhle případě jde, je nějak vhodně to syntakticky pocukrovat.

Například takhle:

class A
{
private:
  B b::(*);   // B má metody m1 a m2
  C c::(m3,m4)
  {
    int m4()
    {
      // implementing abstract method
      return 42;
    }
  }
  D d::(^(m1)); // ^(m1) značí vše krom m1, D má metody m1 a m5

public:
  A() :b(new B(...)), c(new C(...))
  {
    //...
    d = new D(...);
  }
}

Neříkám, že takhle to je vhodný způsob, jen mě to tak napadlo coby příklad...

[Ladicek]

Pojmy dědičnost a agregace mají svůj význam v kontextu objektově orientovaných programovacích jazyků. Nevěděl jsem, že se tu bavíme o přípravě jídla. A nejsou to návrhové vzory, mimochodem.

Z pohledu implementace je samozřejmě konstrukce objektu ve skutečnosti pár trapných operací v paměti. Jenže to mne vůbec nezajímá. Vytvoření objektu by mělo být zavolání metody třídy. (I když si nejsem jistý, jestli se chci pouštět do onanie s třídami coby objekty atd.) Ta se může rozhodnout, že ve skutečnosti vrátí instanci nějaké jiné třídy (podtypu). Ale kde to skončí? Na podobnou notu: Ve Smalltalku je AFAIK každá třída potomkem nějaké jiné třídy. A čím potomkem je ta prapůvodní třída, která stojí v kořeni hierarchie dědičnosti? No, sama sebe. Už chápeš, jakou magii mám na mysli? To je to, co mne zajímá, ne co se děje v nějakém trapném C++.

[kralyk z abclinuxu]

Pojmy dědičnost a agregace mají svůj význam v kontextu objektově orientovaných programovacích jazyků.

Jo? Takže můžu přístupovat stejným způsobem k třídám v C++, Javě, C# a třeba Objective-C? Neřekl bych...

Ve Smalltalku je AFAIK každá třída potomkem nějaké jiné třídy. A čím potomkem je ta prapůvodní třída, která stojí v kořeni hierarchie dědičnosti?

Je bez rodiče. Stejný to je v Object Pascalu - tam mají TObject.

Už chápeš, jakou magii mám na mysli?

Ne, to teda nechápu, já tam žádnou magii nevidim...

[Ladicek]

No, třídy v C++, Javě, C# a ObjeCu jsou ve skutečnosti prakticky stejné, takže ano A agregace a dědičnost jsou dostatečně obecné koncepty na to, abys je mohl aplikovat i na ten Object Pascal, Simulu, Eiffel, Smalltalk, Ruby, Python a já nevím co ještě, i když se ty jazyky od sebe navzájem v jiných ohledech významně liší. (A rozdíl mezi vícenásobnou a jednoduchou dědičností je fakt minimální.)

No dobře, seš prostě Céčkař, zajímá tě implementace a filozofickou stránku věci neřešíš. Já jo, takže mne nejvíc zajímají "hraniční" případy. Konstruktor je takový hraniční případ: Je to metoda/funkce, která dělá něco, co žádná jiná metoda nedělá a dělat nemůže (a to se týká i jazyků s explicitní správou paměti – no i když, nejspíš by sis mohl v C++ ručně alokovat paměť, vyplnit hlavičku objektu, inicializovat všechny položky a pak ten ukazatel přetypovat, ale kdo by to dělal?). Dá se tomu vyhnout? Netoužím po vyloženě čistém jazyku, ale způsob, jak se vytváří objekty a hlavně jak se spojují dohromady do grafu, který tvoří aplikaci, je z praktického hlediska velmi důležitý (proto už jsem tady několikrát zmiňoval DI).

[kralyk z abclinuxu]

Hm, zřejmě si rozumíme, akorát pro to máme každej jiný slova...

ale způsob, jak se vytváří objekty a hlavně jak se spojují dohromady do grafu, který tvoří aplikaci, je z praktického hlediska velmi důležitý (proto už jsem tady několikrát zmiňoval DI).

S tím naprosto souhlasím. Mohli bychom říct, že aplikace je (z tohohle hlediska) nějaký graf objektů, buď to strom, nebo alespoň DAG, v něm jsou objekty rodičovské, potomci, a mezi nima nějaká "dědičnost" ... teď ale nemyslim tu konktrétní dědičnost známou z běžných OOP jazyků, ale obecně jakoukoli dědčinou, ať už se realizuje pomocí "běžné" dědičnosti, pomocí agregace nebo pomocí jánevím čeho. Pak tam samozřejmě existují všelijaké další vazby... Někteří lidé je rádi pojmenovávají... Takže už zbývá "jenom" to, jak to vyjádřit programovacím jazykem.

Já bych osobně nejradši jazyk, který by poskytoval co nejvěší volnost a zároveň obsahoval syntaxi pro realizaci co nejvíce možných způsobů těch vazeb. Čili by asi (částečně) obsahoval nějakou meta-syntaxi. V tomhle se mně právě u D libí operator overloading - poskytuje opravdu velkou volnost.

[Josef Kufner]

Že to bude alespoň DAG není vůbec jisté. Cyklické vazby v aplikaci jsou celkem běžná věc – např. když dva objekty sledují nějaké (různé) události a navzájem se informují o stavu nebo třeba strom widgetů v okně, kde potomci mají jak reference na rodiče, tak seznam svých potomků. Přecejen, tady nejde o datové typy (třídy), ale o jejich instance.

[kralyk z abclinuxu]

No jasný no, ono v tom grafu určitě nebudou jen hrany jednoho typu, ale bude jich tam celkem hafo

[Radek Miček]

Mohli bychom říct, že aplikace je (z tohohle hlediska) nějaký graf objektů, buď to strom, nebo alespoň DAG

Mohl by to být i graf s cykly s tím, že by pak mezi objekty nebyl vztah částečného uspořádání ale jen předuspořádání.

[Ladicek]

Metaprogramování beru jako důležitou součást programování, ale tak daleko jsem se ve svém myšlenkovém experimentu s "rozumným" jazykem ještě nedostal

Přetěžování operátorů s použitím jmenné konvence pro metody se mi docela líbí, pokud teda na přetěžování operátorů přistoupím, a koukám, že chlapci v D se docela snaží i řešit asociativitu (ne jako ve Scale, kde se asociativita operátoru pozná podle toho, jestli je posledním znakem dvojtečka ), to je pěkné.

[kralyk z abclinuxu]

Jo a taky co se mi líbí je, že D má kontrolovatelný GC. Že si můžu vybrat kdy ho pustim a kdy ne...

[pavlix]

Ono je rozdíl mezi konstruktorem v C++ a funkcí, která vytváří objekt, že. Třeba GObject i Python tohle mají rozlišené. V GObjectu jsou to funkce *_new a *_init, v Pythonu speciální metody __new__ a __init__. To je myslím docela pěkné řešení.

Jen mě překvapuje, že v céčkovském GObjectu (pokud si správně pamatuju) se *_init řetězí automaticky (tzn proběhne inicializace podle předků), zatímco v Pythonu se musí nadřazený init volat explicitně. Před týdnem jsem se na tom spálil na svém vlastním školení.

DI to je to, o čem se tak strašně zmateně píše na rootu?

[Ladicek]

DI to je to, o čem se tak strašně zmateně píše na rootu?

To je ono. Mluví se o tom už víc než deset let, ale do světa PHP se to dostalo až teď

[pavlix]

Já jen že tam byly akorát nějaké nesrozumitelné kecy :), takže jsem ještě nenarazil na text, který by mě navnadil o tom zjišťovat nějak více.

[Ondrej 'SanTiago' Zajicek]

Vytvoření objektu by mělo být zavolání metody třídy.

A proc? Tohle me vzdycky prislo zbytecne svihle. Konstruktory objektu bych nechal jako normalni samostatne funkce (nikoliv metody objektu/trid/cehokoliv), a bylo by po problemu.

[Josef Kufner]

Beztak se to tak často dělá ... a vznešeně se tomu říká factory.

[pavlix]

Factory ale bývá často implementována jako instance samostatné k tomu určené třídy, spíše než jako funkce. Navíc, kdo někdy psal v céčku či trochu více v pythonu, tak je mu jasné, že metoda a funkce jsou v podstatě úplně to samé.

Přijde mi, že pro nejjednodušší případy je ideální použít speciální metodu typu __init__ (tedy pouze jednoduše inicializovat), na trochu složitější (singletony a jim podobné) ještě __new__. Tyhle dvě volat implicitně (pomocí syntaxe, ale například GObject v C to musí mít explicitně), a pro ostatní případy používat Factory objekty.

[Josef Kufner]

To, že to bývá instance třídy je spíš použitým jazykem a tím, že se Factory nepoužívá na triviální operace.

[pavlix]

To, že to bývá instance třídy je spíš použitým jazykem a tím, že se Factory nepoužívá na triviální operace.

To je naprosto v pořádku. Mezi náma, metoda __new__ v Pythonu má taky schopnost vracet jiný objekt, než o který si uživatel řekl. Takže taky funguje jako factory funkce dokonce má k dispozici stav třídy, tzn třída funguje jako factory objekt. Ale fakt je, že když chci opravdový factory objekt, vytvářím ho samostatně kvůli čistotě kódu.

[Ladicek]

Protože se snažím vyhnout globálním (statickým) proměnným a funkcím Možná žádné lepší řešení není, nevim.

[Josef Kufner]

Pokud to má být schopné dosáhnout stejných výsledků ze stejných vstupů, tak dříve či později zjistíš, že ty přístupy jsou ekvivalentní a navzájem převeditelné. Otázkou je jen pohodlí, přehlednost a praktická použitelnost (plus z toho vyplývající vlastnosti jako chybovost programátora).

[Ladicek]

A pak zjistíme, že všechny programovací jazyky jsou ekvivalentní, což je hrozně úchvatný výsledek, jenže naprosto neužitečný. Vyjadřovací síla všech programovacích jazyků je stejná, ano. Prostředky, kterými se jí dosáhne, nikoliv.

[Radek Miček]

Vyjadřovací síla všech programovacích jazyků je stejná, ano.

To není pravda.

[Ladicek]

Jejda, já zase zapomněl na dokazovače teorémů. BS, pokud jde o mne.

[Josef Kufner]

Jakpak to?

[----]

např. Cčko má větší vyjadřovací sílu než nějaký minimalistický VM-based jazyk v sandboxu.

[Josef Kufner]

Ok

[Radek Miček]

Třeba jazyky, jenž garantují konečnost programů.

[Ladicek]

Já bych tady jenom upozornil neznalé čtenáře, že tyhle akademické hračky lze nalézt pod názvy jako (automated) theorem prover nebo proof assistant a programovací jazyk tomu neříká téměř nikdo (natožpak aby v tom programoval). Technicky ale o programovací jazyk jde, takže je samozřejmě pravda, že různé jazyky mají různou vyjadřovací schopnost. Pro běžnou diskusi, jako je tahle, obvykle stačí pod pojmem programovací jazyk předpokládat turingovsky úplný programovací jazyk a vědět, že se můžou objevit puntičkáři

[petr_p]

Perl má nad metaobjektovým protokolem postavený systém zvaný Moose, který má delegace, traits, role a tak dále.

[Ladicek]

Přiznám se, že jsem to z té odkazované stránky moc nepobral, ale je fakt, že dynamické jazyky s dostatečně širokým MOPem umožňují doprogramovat si prakticky cokoliv. Já měl tak nějak automaticky na mysli staticky typované jazyky, moje chyba.

[LangPa]

Chtělo by to jazykovou podporu pro delegaci...

Pokud jsem to pochopil, tak takovou delegaci umí Delphi (Object Pascal). Funguje to tak, že třída implementuje interface přez nějakou property, která implementuje daný interface. Je ale potřeba co nejdříve (např v konstruktoru) property nastavit na platnou instanci

type
  TMyClass = class(TParent, IInterface1)
  private
    FInterface1: IInterface1;
  public
    constructor Create;

    property Interface1:IInterface1 read FInterface1 implements IInterface1;
  end;

Bohužel nevím, jak je to nyní, ale ve Free Pascalu s tímto byly problémy, ale jako jazyková vlastnost je to specialitka. Pascal jsem se časem odnaučil mít rád, ale tohle mě párkrát v C# chybělo.

[Ladicek]

Přiznám se, že rozhraní v Object Pascalu jsem nikdy moc nepochopil, přišlo mi, že je to hrozně těsně vázané na COM a tudíž ne obecně použitelné. Ale ten kód, co uvádíte, dává smysl. Budu nad tím ještě kontemplovat

[LangPa]

Je ale potřeba si uvědomit, že jakmile někdo získá daný interface, jsou dvě možnosti realizace:

1. Objekt předá jiný objekt implementující daný interface a již není možné danou instanci vyměnit, byť je možné změnit obsah fieldu a kód se chová prapodivně nekonzistentně
2. Jazyk generuje v rámci objektu wrapery a vše je v pořádku, ale reálný strojový kód provádí dereferenci navíc a jedná se o komplexnější "syntaktický cukr"

V Object Pascalu je také vcelku jednoduché používat vzor "virtuální konstruktor", načež spousta jazyků potřebuje obejití pomocí factory method, paradoxně některé tyto vymoženosti skrývají chování (behaviorální vlastnosti) a snižují pochopitelnost kódu při vyšší komplexnosti struktur tříd (když je toho hafo souborů ).

Možná zamotané souvětí, ale některý kód může vypadat ještě složitější Naštěstí jde používat debugger, který rozumí obsahu struktur, což je v dynamických jazycích obtížněji prezentovatelné, a kdo má potřebu, nakonec pochopí o co jde.

Interface v Object Pascalu fungují stejně jako interface v jiných jazycích, akorát že je možnost je používat ve spojení s technologiemi COM, DCOM a nejspíš už i .NET. Potíž s interfacy v Object Pascalu byla ta, že je většina programátorů chápala pouze takto a ne jako další prostředek jak expresivně vyjádřit svůj názor na další vývoj a rozvoj kódu. Chovám bláhovou naději, že se situace změnila. Dnes i PHP podporuje interface i když ty PHP standartní jsou atypické vzhledem k praxi zavedené v Javě i .NET a nejspíš atypické i z pohledu programátorů v ostatních jazycích.

[Ladicek]

První možnost přináší až moc problémů. Tu druhou, pravda, nelze optimalizovat při překladu, ale techniky adaptivní optimalizace za běhu už jsou dneska dost rozvinuté na to, aby to v pohodě zvládly.

Jinak ten Object Pascal, zdá se, umí víc věcí, než jsem myslel. Ale já naposledy používal Delphi 6, a to už je fakt nějaká doba

[pavlix]

Pokud se bavíme o tom, že interface má nějakou implementaci, tak to už není interface ve smyslu, že lze vícenásobně zdědit/implementovat pokud není povolená vícenásobná dědičnost.

Parse error.

Pokud implementaci vyhodím do další třídy, tak je to právě to psaní navíc jen abych dostál nemožnosti vícenásobné dědičnost, ale principiálně je to „workaround“ a způsobí právě to, že se více píše.

Asi jsem to špatně pochopil, myslel jsem, že „psaním navíc“ bylo myšleno zbytečné opakování kódu. Pokud jde o hlavičku jedné třídy navíc, tak pak beru zpět, že se v tomto shodnem. To mě u vícenásobné dědičnosti či interface opravdu netrápí.

Mně osobně spíš jako workaround přijde implementace vícenásobné dědičnosti třeba v C++.

A jiném případě se zas musí zapouzdřovat a zveřejňovat a zas je to více psaní (zapouzdření není vždy ten správný přístup, i když bezpečný). Pokud se použije nějaká názvová konvence a používá se to „přímo“ ve „finální“ třídě, obvykle žádné problémy nenastanou, a efektivita je vyšší a čitelnost či přehlednost to neovlivní.

Parse error.

Si prostě myslím, že vícenásobná dědičnost není zlo, zlo je když se používá místo „interface“ a její odstranění považuji za zbytečnou obstrukci jazyka.

Nikde jsem nepsal, že je. Jen se mi nelíbí vícenásobná dědičnost à la C++, a tím pádem vícenásobná dědičnost ve všech jazycích, které se budou snažit optimalizovat do stejné míry jako C++.

[Šangala]

První „parse error“:
No pokud obsahuje interface nějakou implementaci není to již interface, ale například abstarktní class a tudíž se neimplementuje, ale dědí a pokud nelze dědit vícekráte tak je to stopka, pokud chceme dědit s obou.

To psaní: Ano hlavička další třídy, komentáře a volání dané metody a případné nadbytečné předávaní nějakých parametrů - ano to jsem myslel

Druhý „parse error“:
No to je druhý případ psaní navíc, class má používat(dědit) třeba dvě třídy a rozhraní obou tříd má být veřejné. Takže pokud nelze dědit vícenásobně, tak se instance class-ů zapouzdří a buď se zveřejní metoda (getter) jednotlivých instancí (což má své nevýhody). Nebo se jednotlivé fce napíší znovu a jejich obsahem je jen provolání jednotlivých fcí zapouzdřených instancí.
A efektivita kódu jde do háje a zvyšují se nároky <joke>a máme z toho Javu</joke> .

Jsem rád, že vícenásobná dědičnost není zlo - nebo, že aspoň někdo si to nemyslí . V minulosti to bylo kontroverzní téma, fčul už je to většinou klasifikováno jako zlo, (zlé) jazyky který touto možností nedisponují, závidí .

[pavlix]

No pokud obsahuje interface nějakou implementaci není to již interface, ale například abstarktní class a tudíž se neimplementuje, ale dědí a pokud nelze dědit vícekráte tak je to stopka, pokud chceme dědit s obou.

To už je o něco srozumitelnější. To, že interface má přiřazené už nějaké hotové metody podle mě ještě nutně neimplikuje, že je to abstraktní třída (tzn že to má všechny vlastnosti, co abstraktní třída v daném jazyce). Nejspíš je to mixin.

To psaní: Ano hlavička další třídy, komentáře a volání dané metody a případné nadbytečné předávaní nějakých parametrů - ano to jsem myslel

Tak kvůli tomu bych se s vícenásobnou dědičností netrápil, pokud nejde implementovat nějak hezky a čistě.

[pavlix]

No to je druhý případ psaní navíc, class má používat(dědit) třeba dvě třídy a rozhraní obou tříd má být veřejné. Takže pokud nelze dědit vícenásobně, tak se instance class-ů zapouzdří a buď se zveřejní metoda (getter) jednotlivých instancí (což má své nevýhody). Nebo se jednotlivé fce napíší znovu a jejich obsahem je jen provolání jednotlivých fcí zapouzdřených instancí.

No... když vezmu dvě zcela nezávisle vytvořené třídy... a chci od obou dědit... tak budu mít docela problém s kolizemi, ne? Stejně nad tím nakonec budu muset postavit nějaký slušný interface, takže mám za to, že toho psaní navíc tak moc nebude a ta efektivita zdaleka jít do háje nemusí.

[Sten]

S kolizemi problém být nemusí a C++ to umí řešit pomocí „using“ či explicitní specifikace nadřazené třídy. Prostě u těch kolizí můžete říct, ze které třídy to chcete přednostně používat:

class A
{
public:
    void delej();
};


class B
{
public:
    void delej();
};


class C
    : public A
    , public B
{
public:
    using A::delej;
};


C c;
c.delej(); // A::delej()
c.B::delej(); // Explicitně chceme delej z B

[pavlix]

Už jen to, že se ten problém řeší, dokazuje, že existuje :).

[Michal Kubeček]

Asi si zase nadělám pár nepřátel, ale musím konstatovat, že nechápu všechny ty komentáře typu "super článek". Podle mne je ten článek z didaktického hlediska naopak velmi špatný. Tedy aspoň pokud byl zamýšlen jako výukový.

Článek mi připomněl jeden odstrašující příklad, jak by se učit nemělo, v osobě našeho učitele informatiky na gymnáziu (paradoxně zaměstnance KDM MFF UK). Typická hodina vypadala tak, že přišel, prohlásil: "Tak dneska si probereme pole. Pole se deklarují takhle: ...", napsal na tabuli syntaxi a když jsme měli štěstí, přidal i nějaký příklad. Pak nám dal nějaké zadání a nechal nás, ať se snažíme. Přičemž vůbec nevysvětlil, co to takové pole vlastně je a k čemu slouží. Výsledek? Kdo už Pascal uměl, ten se nic nedozvěděl, kdo ne, stejně neměl šanci to z jeho výkladu pochopit, takže byl odkázán na následný výklad od spolužáků.

Proč o tom mluvím? Protože tento článek funguje přesně stejně. Místo aby se začlo nějakým "filosofickým" úvodem o jazyce jako takovém, autor hned začne bez jakéhokoli systému chrlit úkázky, které ani moc neokomentuje, takže nám nezbývá než se dohadovat, jestli to int[string] je asociativní pole či co, co je to vlastně ten "mixin", proč má "UTF-8" znak maximální hodnotu 255 atd. Prostě jen výčet "podívejte se, co to všechno umí". A stejně jako v předchozím odstavci: kdo jazyk zná, tomu to nic nedá (až na ten příjemný pocit "jo, to znám"), kdo ho nezná, tomu také ne. Prostě to celé působí jako screenshotová "recenze" nové verze distribuce, ne jako výukový článek.

Neberte to jako že vás chci nějak strhat; vlastně jsem se ještě ani nepodíval, kdo je autorem, a záměrně to neudělám, dokud tento komentář neodešlu. Naopak, snažím se vám pomoci, protože nadšené komentáře "super článek" vám nepomohou, ty vás jen utvrdí v přesvědčení, že to děláte skvěle, což bohužel vůbec není pravda. Zkuste se nejdřív zamyslet nad tím, komu je článek vlastně určen, a pak si text procházet ne svýma očima (někoho, kdo jazyk zná a používá), ale očima právě té cílové skupiny (která ho dost možná vidí poprvé). A nepostupujte zdola, tj. od konkrétních ukázek demonstrujících nevysvětlené principy, ale naopak shora, tedy od těch principů, které pak teprve demonstrujete na ukázkách.

[----]

Ono jak tam jsou ty pole apod., tak ono ani není záměrem je teď vysvětlit; bude se jim věnovat vlastní kapitola. Ty příklady jsou tam jenom, aby se čtenář trochu seznámil se syntaxí. Řetězce plánuju později podrobně rozebrat, to samé pole, asociativní pole, i ty mixiny ..

[dad]

ja si myslim, ze s vami budou spise rozumni lide souhlasit. Dovolim se vas zapis doplnit o jeden priklad.

Specifikačně, D je multi-paradigm, s podporou imperativního programování jako v C, objektového/generického/meta jako v C++, i funkcionálního a konkurentního. Hlavními zdroji inspirace jsou C, C++, Java, Python, Ruby, C# a Eiffel. I když je D high-level jazyk, podporuje i kompletně low-level přístup, včetně inline assembly.

D používá statické/silné typování a podporuje všechny Cčkové POD typy. Imperativní programování je velmi podobné Cčku, objektový systém přebírá z Javy (nemá vícenásobnou dědičnost, místo toho používá interfaces/mixins), modulový systém je podobný Pythonu. Kromě toho se inspiruje z velké části C++.

- muj prvni problem bylo to 'je multi-paradigm'

- 's podporou imperativního programování jako v C' - to na me pusobi, jako kdyby D byl deklarativni jazyk (a nebo funcionalni - jine typy neznam)

- 'objektového/generického/meta' - zde vubec nevim co je mysleno

- '..a konkurentního' - aha, takze krome imperativni, deklarativni a funcionalni existuje i 'konkuretntni' jazyky. (uvidime, co na to rika google)

- 'inspirace jsou C, C++, Java, Python, Ruby, C# a Eiffel.' - hm, z nich znam jenom to C

- 'podporuje všechny Cčkové POD typy' - zase google

- 'objektový systém přebírá z Javy (nemá vícenásobnou dědičnost, místo toho používá interfaces/mixins)' - ja ale Javu neznam, je to ted dobry, ze neni ta vicenasobna dedicnost, co jsou to 'mixins'?

- 'modulový systém je podobný Pythonu.' - tak to je senzace, skoda jen ze nevim, jak takovy modulovy system u Pythonu vypada.

Muj dojem, kdyz jsem to precetl je, ze autori toho jazyka necetli tu pohadku Josefa Capka o te kocicce a pejskovi. Ale neco jsem si presto z clanku odnesl. Ten dort, co kocicka s pejskem pekla byl patrne 'multi-paradigm'

[JoHnY2]

Ale neco jsem si presto z clanku odnesl. Ten dort, co kocicka s pejskem pekla byl patrne 'multi-paradigm'

Malem jsem smichy spadnul ze zidle.

[100% Lenin]

Zlatej Fortran. Kam ten svět spěje :D:D:D

[Tosak]

súhlasím, ani ja som sa z toho článku moc nedozvedel (-;

[Luboš Doležel (Doli)]

Však je to úvod. Na konci článku přece autor píše, že bude jednotlivé věci probírat konkrétně.

[KarelI]

Myslim, ze vychazite z mylnych predpokladu. Predpokladate, ze clanek ma za cil ucit programovani, ovsem uz od zacatku je zrejme, ze ma ucit programovani v D. Ja jelikoz programovat umim, tak jsem rozumel vsemu aniz bych o D neco predtim vedel, cili z meho pohledu je clanek presne takovy jaky ma byt - hutny, strucny Filosoficky uvod o jazyce byl v prvni casti, imho dostatecny, prikladum z kodu jsem rozumel, napr. ty hodnoty jsem pochopil jako defaulty, je to zrejme z toho prikladu, zkuste se na nej podivat znovu.

Cili zaver - D jsem neznal, clanek jsem pochopil, tedy spor s vasi tezi. Pokud se chcete naucit programovat, nactete si neco jineho a ja se pripojuji k oslavovatelum a prosim autora, aby styl zachoval

[Michal Kubeček]

Obávám se, že jste můj příspěvek vůbec nepochopil.