Ideálny programovací jazyk

[Johnny]

No jenže pokud ale mají oba pouze 50 Kč, pak opravdu jo:

V jazyce, který umožňuje používat hodnoty i reference, musí programátor znát rozdíl mezi hodnotou a referencí. To je celé, nic dalšího k tomu není potřeba dodávat, kdo ten rozdíl chápe, chápe i hloupost vašich příspěvků.

Já nejsem ten, který tady ze sebe dělá hlupáka. Jednou se to rovná, a podruhé ne. Právě ten, kdo chápe ten rozdíl, by nad tím měl kroutit hlavou...

[Reklama]

[Idris]

No jenže pokud ale mají oba pouze 50 Kč, pak opravdu jo:

Vždyť jo - pokud má Pepa a Franta jenom 50Kč, tak jsou to socky a pro javisty je socka jako socka.

[Idris]

No jenže pokud ale mají oba pouze 50 Kč, pak opravdu jo:

V jazyce, který umožňuje používat hodnoty i reference, musí programátor znát rozdíl mezi hodnotou a referencí. To je celé, nic dalšího k tomu není potřeba dodávat, kdo ten rozdíl chápe, chápe i hloupost vašich příspěvků.

Já nejsem ten, který tady ze sebe dělá hlupáka. Jednou se to rovná, a podruhé ne. Právě ten, kdo chápe ten rozdíl, by nad tím měl kroutit hlavou...

To je podobné jako porovnání stringů pomocí ==. Ano, je to zastaralé, nezvyklé a nebezpečné, ale tak se prostě Java chová. Moderní jazyky to už většinou mají lépe.

[Mirek Prýmek]

V jazyce, který umožňuje používat hodnoty i reference, musí programátor znát rozdíl mezi hodnotou a referencí. To je celé, nic dalšího k tomu není potřeba dodávat, kdo ten rozdíl chápe, chápe i hloupost vašich příspěvků.

Na upozornění na kontrainutitivnost nějakého prvku jazyka není nic hloupého.

[Jiří Havel]

Java také nebude ten ideální jazyk... 

Kód: (Java) [Vybrat]

public class HelloWorld
{
  public static void main(String[] args)
  {
    Integer a = 1024;
    Integer b = 1024;
    System.out.print(a == b); // false
  }
}

Vysvětlil by mi někdo, co se tam děje? Kdyby to bylo něco mimo rozsah 32b intu, tak bych to pochopil. Ale 1024 je furt zatraceně málo.

[Reklama]

[Filip Jirsák]

Vysvětlil by mi někdo, co se tam děje? Kdyby to bylo něco mimo rozsah 32b intu, tak bych to pochopil. Ale 1024 je furt zatraceně málo.

Integer v Javě je objekt, operátor == v Javě porovnává reference. Takže si v tom kódu vytvoří objekt(y), reference na ně jsou uložené do dvou proměnných – a pak zjišťuje, zda ty dvě reference ukazují na stejný objekt.

To, že ty reference někdy mohou ukazovat na stejný objekt je dané tím, že v kódu převádí primitivní typ int (zapsaný literálem 1024) na objektový Integer. Javovský kompilátor má vestavěný mechanismus (nazývaný boxing), který ten převod dělá automaticky. A nepoužívá se při tom konstruktor, ale statická metoda – a ta statická metoda vytváří nové objekty jenom pro větší čísla. U menších čísel má pool instancí a vrací ty instance – aby v paměti neexistovalo tisíc objektů, které v sobě ponesou hodnotu „1“.

Skoro stejně to funguje se Stringy, a v případě Stringů se to učí asi tak ve druhé lekci, že se neporovnávají pomocí == ale pomocí equals(), protože == porovnává reference a mohou existovat dva různé objekty, které obsahují ten samý řetězec.

Na upozornění na kontrainutitivnost nějakého prvku jazyka není nic hloupého.

Hloupé je to, že uvádí jeden okrajový příklad, a zdá se, že vůbec nechápe podstatu. To, že operátor == v Javě porovnává hodnoty primitivních typů a reference u objektů mi nijak neintuitivní nepřipadá. Napadají mne jen dvě srovnatelně dobrá řešení a žádné lepší. Jedno řešení by bylo pro objekty == udělat jako alias pro equals() a ošetřit null hodnoty. Druhé řešení by bylo == pro objekty úplně zakázat. V obou případech by na porovnání referencí musel existovat nějaká systémová metoda.

[BoneFlute]

Java také nebude ten ideální jazyk... 

Kód: (Java) [Vybrat]

public class HelloWorld
{
  public static void main(String[] args)
  {
    Integer a = 1024;
    Integer b = 1024;
    System.out.print(a == b); // false
  }
}

Vysvětlil by mi někdo, co se tam děje? Kdyby to bylo něco mimo rozsah 32b intu, tak bych to pochopil. Ale 1024 je furt zatraceně málo.

Integer je v Javě objekt (na rozdíl od int). A k objektům se přistupuje vždy odkazem a nikoliv hodnotou. Tudíž výraz a == b neporovnává dvě shodná čísla, ale dva různé odkazy na stejné číslo.

[Filip Jirsák]

Já nejsem ten, který tady ze sebe dělá hlupáka. Jednou se to rovná, a podruhé ne. Právě ten, kdo chápe ten rozdíl, by nad tím měl kroutit hlavou...

Vážně byste si měl nastudovat rozdíl mezi hodnotou a referencí. Představte si, že máte na tabuli napsaná čísla, a pak tam přidáváte šipky, které na ta čísla ukazují. Na jedno číslo může ukazovat víc šipek. To, že máte v ruce dvě různé šipky, neznamená, že obě šipky nemohou ukazovat na stejné číslo. Pokud chcete porovnávat čísla, musíte se dívat, kam šipka ukazuje, ne na šipku samotnou.

[BoneFlute]

Já nejsem ten, který tady ze sebe dělá hlupáka. Jednou se to rovná, a podruhé ne. Právě ten, kdo chápe ten rozdíl, by nad tím měl kroutit hlavou...

Vážně byste si měl nastudovat rozdíl mezi hodnotou a referencí. Představte si, že máte na tabuli napsaná čísla, a pak tam přidáváte šipky, které na ta čísla ukazují. Na jedno číslo může ukazovat víc šipek. To, že máte v ruce dvě různé šipky, neznamená, že obě šipky nemohou ukazovat na stejné číslo. Pokud chcete porovnávat čísla, musíte se dívat, kam šipka ukazuje, ne na šipku samotnou.

A vo tom to není, že áno. Nepochybuji o tom, že rozdílu mezi hodnotou a referencí moc dobře rozumí.

[Mirek Prýmek]

Hloupé je to, že uvádí jeden okrajový příklad, a zdá se, že vůbec nechápe podstatu.

Porovnani dvou cisel mi neprijde nijak okrajove. A jestli chape nebo nechape podstatu, 1. neumim z niceho odvodit, 2. je to irelevantni - porad je ta vec kontraintuitivni.

To, že operátor == v Javě porovnává hodnoty primitivních typů a reference u objektů mi nijak neintuitivní nepřipadá.

Je to kontraintuitivni - jestlize o Jave nic nevim, muzu si rict tak leda "WTF" - vubec me nenapadne, proc by se to jednou melo chovat tak a jindy jinak.

Uz to samotne vase "jenom pro větší čísla" ukazuje na neco, co vypada divne. "Vetsi cisla"? To je co? Vime to? Je to nekde v dokumentaci? Nebo se to chova "nahodne" (podle toho, jak velky je zrovna ten pool)?

Napadají mne jen dvě srovnatelně dobrá řešení a žádné lepší. Jedno řešení by bylo pro objekty == udělat jako alias pro equals() a ošetřit null hodnoty. Druhé řešení by bylo == pro objekty úplně zakázat. V obou případech by na porovnání referencí musel existovat nějaká systémová metoda.

Tak dalsi mozne reseni by bylo (pokud jsem spravne pochopil princip) nemit ten pool pro "mensi cisla"?

Jinak existuje urcite aspon pet, ne-li vic moznych jinych reseni, ale nektere z nich by vyzadovaly nejake featury, ktere aktualne Java asi nema.

[Mirek Prýmek]

Tak dalsi mozne reseni by bylo (pokud jsem spravne pochopil princip) nemit ten pool pro "mensi cisla"?

...anebo ho naopak mit povinne (tak to ma treba Erlang s atomy - zarucene vzdycky jsou stejne atomy "unifikovane"). Proste aby se to chovalo tak nebo tak, ale konzistentne, predvidatelne.

[Jiří Havel]

Integer v Javě je objekt, operátor == v Javě porovnává reference...

Dík, zmátlo mě to cachování malých integerů. Ani z toho, že == má porovnávat reference jsem nebyl schopný vydedukovat, co se tam děje.

To, že operátor == v Javě porovnává hodnoty primitivních typů a reference u objektů mi nijak neintuitivní nepřipadá.

Rozhodně je to nekonzistentní. že budou vestavěné typy a objekty podporovat jiné operace bych bral, že ale stejná operace funguje na obou jinak mi přijde jako past na nováčky.

Napadají mne jen dvě srovnatelně dobrá řešení a žádné lepší. Jedno řešení by bylo pro objekty == udělat jako alias pro equals() a ošetřit null hodnoty. Druhé řešení by bylo == pro objekty úplně zakázat. V obou případech by na porovnání referencí musel existovat nějaká systémová metoda.

Intuitivní by mi přišlo mít dvě porovnání, jedno na identitu a jedno na hodnotu, a nechat je chovat se konzistentně pro všechno. Samotná syntaxe těch dvou porovnání už je vlastně detail.

[Idris]

Vysvětlil by mi někdo, co se tam děje? Kdyby to bylo něco mimo rozsah 32b intu, tak bych to pochopil. Ale 1024 je furt zatraceně málo.

Integer v Javě je objekt, operátor == v Javě porovnává reference. Takže si v tom kódu vytvoří objekt(y), reference na ně jsou uložené do dvou proměnných – a pak zjišťuje, zda ty dvě reference ukazují na stejný objekt.

To, že ty reference někdy mohou ukazovat na stejný objekt je dané tím, že v kódu převádí primitivní typ int (zapsaný literálem 1024) na objektový Integer. Javovský kompilátor má vestavěný mechanismus (nazývaný boxing), který ten převod dělá automaticky. A nepoužívá se při tom konstruktor, ale statická metoda – a ta statická metoda vytváří nové objekty jenom pro větší čísla. U menších čísel má pool instancí a vrací ty instance – aby v paměti neexistovalo tisíc objektů, které v sobě ponesou hodnotu „1“.

Skoro stejně to funguje se Stringy, a v případě Stringů se to učí asi tak ve druhé lekci, že se neporovnávají pomocí == ale pomocí equals(), protože == porovnává reference a mohou existovat dva různé objekty, které obsahují ten samý řetězec.

Na upozornění na kontrainutitivnost nějakého prvku jazyka není nic hloupého.

Hloupé je to, že uvádí jeden okrajový příklad, a zdá se, že vůbec nechápe podstatu. To, že operátor == v Javě porovnává hodnoty primitivních typů a reference u objektů mi nijak neintuitivní nepřipadá. Napadají mne jen dvě srovnatelně dobrá řešení a žádné lepší. Jedno řešení by bylo pro objekty == udělat jako alias pro equals() a ošetřit null hodnoty. Druhé řešení by bylo == pro objekty úplně zakázat. V obou případech by na porovnání referencí musel existovat nějaká systémová metoda.

Lepší by pochopitelně bylo přetížení operátoru ==.

[Filip Jirsák]

Porovnani dvou cisel mi neprijde nijak okrajove. A jestli chape nebo nechape podstatu, 1. neumim z niceho odvodit, 2. je to irelevantni - porad je ta vec kontraintuitivni.

Jenže on neporovnává dvě čísla, ale dvě reference.

Je to kontraintuitivni - jestlize o Jave nic nevim, muzu si rict tak leda "WTF" - vubec me nenapadne, proc by se to jednou melo chovat tak a jindy jinak.

Ano, můžeme navrhnout jazyk, který nebude mít žádné operátory, protože operátory jsou vždy v nějakém případě kontraintuitivní. Nejsem si úplně jistý, jestli by takový jazyk byl přijat s nadšením.

Uz to samotne vase "jenom pro větší čísla" ukazuje na neco, co vypada divne. "Vetsi cisla"? To je co? Vime to? Je to nekde v dokumentaci? Nebo se to chova "nahodne" (podle toho, jak velky je zrovna ten pool)?

Je to v dokumentaci. Ale je to implementační detail. Programátor klidně může zavolat new Integer(1) a vytvoří se nová instance. Pokud chci porovnávat hodnoty, musím použít metodu equals(). Je to úplně stejné, jako u Stringů. Prostě se programátor nemůže spoléhat na to, že někdy na stejnou hodnotu ukazují stejné reference.

Tak dalsi mozne reseni by bylo (pokud jsem spravne pochopil princip) nemit ten pool pro "mensi cisla"?

Nebylo. Pořád to jsou reference.

Jinak existuje urcite aspon pet, ne-li vic moznych jinych reseni, ale nektere z nich by vyzadovaly nejake featury, ktere aktualne Java asi nema.

Pět lepších řešení? Napište alespoň jedno.

[Filip Jirsák]

Lepší by pochopitelně bylo přetížení operátoru ==.

Bylo by to lepší jen při pohledu z rychlíku. Myslím, že programátor například neočekává, že mu při použití operátoru vypadne výjimka.

Některé jazyky umožňují přetěžovat operátory, což pak vede k tomu, že programátor nikdy neví, co se při použití operátoru stane. Java byla navržena jako jednoduchá, takže tohle záměrně neumožnila – a jediné přetížené (ve smyslu „implementované kódem v metodách“) operátory v Javě jsou ty pracující se Stringy. Přičemž samotný objekt String je v Javě final a má speciální podporu kompilátoru. Nebo-li autoři specifikace mohli zaručit, že se metody Stringu implementující operátory budou chovat slušně a operátory nebudou mít žádné nečekané efekty. Pokud byste operátor == přetížil jako volání equals() (a třeba i ošetřil null hodnoty), pořád bude použití toho operátoru volat uživatelský kód, který může vyhazovat výjimky, dělat dotaz do databáze, equals() ani nemusí být komutativní.

Přetížený operátor == by teprve byl pořádně kontraintuitivní.