Kakao v Leopardu - MujMAC.cz - Apple, Mac OS X, Apple iPod

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Seriály

Více seriálů



Software

Kakao v Leopardu

8. listopadu 2007, 10.00 | Po pauze se opět vracíme s dalšími díly seriálu, který se věnuje programování v prostředí Cocoa operačního systému Mac OS X: Leopard je mezi námi, takže je na čase se podívat na to, co nového přinesl programátorům.

Po pauze se opět vracíme s dalšími díly seriálu, který se věnuje programování v prostředí Cocoa operačního systému Mac OS X: Leopard je mezi námi, takže je na čase se podívat na to, co přinesl nového programátorům.

Ačkoli mezi novinkami snad nejsou tak zásadní balíky, jako byla Core Data v době Tygra – mimochodem, dle mých zkušeností jedno z nejošklivějších zklamání: Core Data jsou skvěle navržena, leč prachmizerně implementována, a obsahují řadu velmi nepříjemných chyb a problémů. Bohužel, jak se zdá, Leopard tuto tradici dodržel (vůbec mám v poslední době nepříjemný dojem, že čím více úsilí Apple vkládá do všelijakých iPhonů a iPodů, tím méně času zbývá na software) –. Nových věcí je dost a dost na to, aby nám vystačily na několik zajímavých dílů.

Objective C 2.0

před časem jsme psali, že po dlouhých letech, kdy nebylo zapotřebí do jazyka Objective C nikterak zasahovat, se firma Apple rozhodla jazyk rozšířit a vylepšit doplněním nových služeb.

Ukážeme si je samozřejmě podrobně i s jejich výhodami a nevýhodami: ti, kdo měli až dosud hrůzu z paradigmatu retain/release, jistě potěší, že Objective C nyní podporuje plně automatický garbage collector. Přitom původní systém správy paměti je stále k dispozici a každý proces si může vybrat to, co jeho programátorovi lépe vyhovovalo: pohodlnější GC, nebo efektivnější retain/release.

64 je dvakrát tolik než 32

Ani o podpoře 64bitového režimu práce jsme se před časem nezapomněli zmínit; tehdy ovšem operační systém obsahoval knihovny a další podporu jen v omezené míře, pouze pro "obyčejné programy" – runtime Objective C a naše Kakao měly smůlu.

Leopard to změnil: od nynějška je k dispozici plně 64bitový režim práce i v Objective C a pro všechny standardní knihovny Apple; změny a nové možnosti, jež to přineslo, nám rozhodně vystačí na samostatný článek.

Nové třídy, nové služby...

Foundation a AppKit ovšem nezůstaly pozadu, a nabízejí řadu nových tříd – a nových služeb ve třídách starých. Obě knihovny samozřejmě nyní plně podporují výše zmíněnou práci ve čtyřiašedesátibitovém režimu; kromě toho máme k dispozici řadu dalších novinek.

Ve Foundation Kitu kupříkladu nalezneme třídy NSOperation a NSOperationQueue, jež pro jednoduché případy nabízejí pohodlnou možnost rozdělení práce do více samostatných vláken, aniž by se programátor musel vůbec něčím takovým zabývat.

AppKit pak nabízí paletu nových možností, zahrnujících kupříkladu předpřipravený editor predikátů, výrazně rozšířený (a snad i opravený) NSTreeController – a že toho měl zapotřebí! –, nové API pro dynamické animace obecných "views" založené na Core Animation, a předlouhou řadu dalších novinek, z nichž si ukážeme alespoň ty nejdůležitější.

... a celé nové knihovny

Novinkou je již zmíněná knihovna Core Animation, jež nabízí možnost velmi pohodlných animací viditelných objektů. Mám sice trochu obavu, zda tyto možnosti nebudou zneužívány pro "pouťově" vypadající aplikace, ale v základu jde o služby velmi rozumné – umožňují snadno zajistit takové věci, že např. uzavření panelu neproběhne skokem, ale dynamicky apod.

Framework Image Kit nabízí řadu služeb pro pohodlnou práci s obrázky, jejich zobrazování i základní úpravy: do jisté míry by se dalo říci, že libovolná aplikace má nyní k dispozici tytéž možnosti jako iPhoto :)

Další zajímavou knihovnou je Calendar Store, jež nabízí přístup k "databázi" tvořící základ kalendáře, jehož uživatelským rozhraním je aplikace iCal; nyní tedy kterákoli aplikace může snadno pracovat s kalendářovými záznamy (podobně, jako již dávno má k dispozici pohodlný framework pro práci s údaji z adresáře).

Velmi zajímavě vypadá Scripting Bridge: tento framework slibuje přímou a nativní podporu pro spolupráci mezi aplikacemi – tedy zhruba to, co nikdy nedokázal pořádně zajistit nenativní a syntakticky poněkud šílený AppleScript. Doufejme jen, že byl nad novou knihovnu přepsán také Automator, a že konečně funguje pořádně!

Ačkoli bohužel nejde o objektový framework, stojí za alespoň stručnou zmínku knihovna FSEvent, jež se stará o předávání notifikací o změnách v systému souborů.

K novým možnostem jsou i nové nástroje

Podobně jako Tygr přišel s Xcode 2, přináší Leopard další velkou versi standardního vývojového prostředí Apple, Xcode 3. Konečně již jde o změnu pouze evoluční a nikoli revoluční – zdá se, že po letech a až příliš mnoha pokusech a slepých uličkách mají konečně u Apple základy vývojového prostředí rozumné a dále na nich staví.

Nové Xcode sice na první pohled vypadá velmi podobně jako "dvojka", přináší však řadu velmi zajímavých novinek, usnadňujících práci a zjednodušujících vývojový cyklus. Rozhodně sem patří např. Research Assistant – velmi šikovné okénko, jež neustále zobrazuje aktuální informace o symbolu, na němž je právě kurzor. Hodně času ušetří i "mini debugger" – plovoucí okénko, jež umožňuje vyvolávat základní služby debuggeru nad libovolnou aplikací, spuštěnou z Xcode, aniž by bylo zapotřebí přepínat do debuggeru. Jakkoli zvýrazňování úrovně vnoření samo působí lehce pouťovým dojmem:

– a to obrázek ani nezachytil, že bíle vyznačená oblast krátce zapulsuje! –, možnost skrývat bloky zdrojového textu, jež je s ním spojena (a jež tak mimochodem po patnácti letech vrátila zpět samozřejmost Editu z NeXTStepu!) je hodně praktická.

Ti, kdo i přes výše zmíněné chyby a problémy využívají knihovnu Core Data, jistě uvítají bohatou podporu tzv. "mapovacích modelů", umožňujících v grafickém prostředí specifikovat postup přechodu od starší verse dat k nové –. Tedy něco, co až dosud bylo nutno velmi pracně programovat.

A aby bylo novinek více, nové Xcode vedle Objective C podporuje také interpretované jazyky Ruby a Python.

Ubicumque dulce est, ibi et acidum invenies: bohužel z Xcode zcela zmizely podpůrné prostředky pro programování ve WebObjects – především nenahraditelný WOBuilder. Ne že by se firma Apple vzdávala WebObjects, právě naopak – součástí Xcode 3 je nová, podstatně rozšířená verse WebObjects 5.4 (mezi její novinky patří kupříkladu nový formát templates, spojující .html i .wod do společného souboru, a řada dalších). Vývojovým prostředím pro WebObjects však nadále nemá být Xcode, nýbrž otevřený javský systém Eclipse s pluginem WOLips. Jakkoli není sporu o tom, že Eclipse jako systém zaměřený a specializovaný na vývoj v Javě dokáže nabídnou daleko lepší služby (ten, kdo někdy zkusil v rámci Xcode spustit javu pod debuggerem ví, co mám na mysli), vůbec z toho nemám radost: mnohem lépe mi vyhovovalo využívat jedno společné IDE pro všechny projekty.

Ostatně stran Javy – zdá se, že u Apple konečně pochopili to, co bylo komukoli, kdo v té věci kdy zkusil programovat, jasné od prvního pohledu: jedná se o kombinaci ďábelské rychlosti Smalltalku s jemnou elegancí C++, a nejenže Java není beznadějně s to konkurovat vývojovému systému založenému na Objective C, ale začíná být zřejmé, že lze lépe a efektivněji vyvíjet i ve výše zmíněných skriptech jako Ruby či Python. Apple tedy tuto slepou uličku zvolna opouští: Java Bridge již není nadále podporován, a sama Java dostává právě takovou pozornost, jakou si zaslouží, to jest mizivou :)

K novému Xcode je také nový Interface Builder; tentokrát jde o změnu revoluční – aplikace je napsána od základu znovu, nabízí přepracované GUI a mnohem lepší integraci s Xcode. Na nový Interface Builder se samozřejmě podíváme velmi podrobně.

Naopak jen velmi stručně se podíváme na aplikaci Dashcode, určenou pro sestavování "widgetů" pro dashboard; ušetřený čas věnujeme podrobnějšímu pohledu na nový univerzální prostředek pro hledání problémů s pamětí i výkonem (nebo čímkoli jiným) v aplikacích – novému programu Instruments.

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Informace  

 » Rubriky  » Agregator  

 » Rubriky  » Tipy a Triky  

 » Rubriky  » Začínáme s  

 » Rubriky  » Software  

Diskuse k článku

 

Vložit nový příspěvek   Sbalit příspěvky

 

Java

Autor: mha Muž

Založeno: 08.11.2007, 10:43
Odpovědí: 0

Java by si rozhodne zasluzila vacsiu pozornost, najma po vyhlaseniach typu \"Mac Os X bude najlepsiou vyvojovou platformou pre Javu\". Dost vela Java vyvojarov prave preto preslo na Mac a to nie kvoli vyvoju pre Mac, ale pre vyvoj roznych J2EE aplikacii. Cize Java Cocoa bridge by som este ozelel, ale ak zacnu kaslat na Javu ako taku, tak to vo mne nevyvolava pocit, ze sa na Apple mozem spolahnut a investovat do tejto platformy aj do buducnosti.

Odpovědět na příspěvek

RE: Java

Autor: OC Muž

Založeno: 08.11.2007, 11:20

Ivestovat cokoli do platformy Java je skutečně dost nesmysl.

Jediné skutečné neštěstí je, že Apple už před lety -- veden bláhovou představou o použitelnosti Javy -- zrušil WebObjects/Objective C :(

Ale třeba se ještě rozhoupou a vrátí to zpátky, technologii na to mají :)

Odpovědět na příspěvek

RE: RE: Java

Autor: kuapi Muž

Založeno: 08.11.2007, 11:41

No tak at se na to vykaslou, ale at pak nechaji volnou ruku Sunu a ostatnim v implementaci Javy pro Mac OS X. To by bylo mozna nejlepsi reseni...

Odpovědět na příspěvek

RE: RE: RE: Java

Autor: OC Muž

Založeno: 08.11.2007, 11:56

Nemohu mluvit samozřejmě za Apple, ale možná k tomu časem dojde. Apple si držel sám Javu právě proto, že ji považoval za strategický tool #1, neboť původně tam -- jak už jsem psal -- byla dost silná iniciativa převést vlastní vývoj z ObjC do Javy. Strašlivá představa,

Naštěst
včas zjistili, jak monstrózní by to byla hloupost, takže se té silné vazby na Javu postupně zbavují; možná to časem skutečně dojde tak daleko, že od ní dají ruce pryč docela.

Odpovědět na příspěvek

RE: RE: RE: RE: Java

Autor: Iwan Muž

Založeno: 08.11.2007, 12:12

Logické je, že Sun dělá s javou jen to, co mu přinese zisk. Sun prodává servery a proto logicky je java výborná pro serverové systémy. Na desktop se jaksi pozapomělo (rozuměj nejsou peníze a tlak). Pokud se podíváte na Sunem podporované platformy, tak to jsou jenom ty, které sám prodává (Linux, Solaris, MSWindows). Takže pokud to nebude dělat Apple, tak asi nikdo.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: Java

Autor: Satai Muž

Založeno: 08.11.2007, 19:27

To samozrejme neni pravda, staci si precist trebas blog Jamese Goslinga - tam vysvetluje, ze Sun by Javu pro Mac OS klidne delal, ale Apple chtel mit jeji vyvoj a integraci do systemu delanou po svem. Vysledky ted vidime ;( To, ze Sun tlaci hlavne Javu na serverech take neni pravda, Java ME je take hodne dulezita a to, ze ji neni tolik videt je zpusobeno odlisnou komunitou vyvojaru. Desktop se ted meni dost radikalne, staci vygooglit zmeny v JSE 5.0 a 6.0, o brzke budoucnosti v podobe Updatu N a Javy Fx nemluve...

Odpovědět na příspěvek

RE: RE: RE: RE: RE: Java

Autor: mha Muž

Založeno: 15.11.2007, 14:35

Kazdy serverovy system potrebuje klientsku cast a tam kde web rozhranie nestaci pride na rad logicky Java. Zhodou okolnosti takmer vsetky produkty s ktorymi som v poslednej dobe prisiel do styku maju klientov v jave. A su to produkty od IBM, CA, HP...

Odpovědět na příspěvek

RE: RE: Java

Autor: Iwan Muž

Založeno: 08.11.2007, 12:01

Jak kolega už psal, je důležité rozlišit JDK/JRE a integraci cocoa do javy.
1) Z Xcode bych javu klidně odstranil - pro návrh multiplatformních aplikací postavených na javě jsou prostředí jako Eclipse a Netbeans.
2) Daleko důležitější je ale podpora JDK/JRE. Tu by měl dělat Apple a měl by ji dělat dobře.

To že java není na desktopové aplikace to nejlepší je sice pravda (poděkujte za to firmě SUN), ale na serverové aplikace se hodně používá a je škoda přijít o uživatele-vývojáře používajících Mac OS X. Aplikace co jsou napsané v javě sice nejsou sexy, ale použitelné jsou.

Odpovědět na příspěvek

RE: RE: Java

Autor: mha Muž

Založeno: 09.11.2007, 13:08

WebObjects na Objective C je podla mna nezmysel. Bol by to krok spat, zavadzanie novej nekompatibility ako tomu bolo s C

Odpovědět na příspěvek

Java jako nesmysl zni dost posetile

Autor: vlk Muž

Založeno: 08.11.2007, 11:37
Odpovědí: 0

Povazovat investici do Javy za nesmysl se mi jevi dosti posetile ... napr, chci-li napsat multiplatformni projekt, ktery docela dobre vypada (SWING), zrovna Java mi nabizi pomerne slusne moznosti s prihlednutim k velmi zdarilemu vyvojovemu prostredi (Eclipse) a mnozstvi veci pro Javu (napr. databazove adaptery, knihovny snad na vsechno atd) a s tim, ze Java je konecne uvolnena pod open licenci nuch naopak docela daval teto platforme zelenou ... pro srovnani napr s MS C# vychazi vykonostne srovnatelne s tim, ze mam multiplatformni aplikaci ... a ohledne te rychlosti ... od dob co Java implementuje JIT tak C++ na tom neni o moc lepe, ba nekdy (zalezi na implementaci) i o dost hure

Odpovědět na příspěvek

RE: Java jako nesmysl zni dost posetile

Autor: OC Muž

Založeno: 08.11.2007, 11:53

Jistěže oproti C# nebo C++ je Java ještě zlatá, to nikdo nezpochybňoval.

Zkust
e ji ale srovnat s Objective C, a je bez šance. A to je právě to, co se Apple nejprve s poměrně značnými investicemi snažil zpochybnit, ale nakonec zkrátka musel uznat.

Swing (a podobné inicativy, včetně multiplatformního AppKitu) jsou cesta do pekel. Má-li multiplatformní projekt dobře vypadat, prostě *musí* mít pro každou platformu specifické GUI.

Odpovědět na příspěvek

RE: RE: Java jako nesmysl zni dost posetile

Autor: kuapi Muž

Založeno: 08.11.2007, 12:11

Chcete-li, muzete prispet svou troskou do mlyna v aktualni diskusi na MujMacu "V cem programovat"...

http:/
/forum.mujmac.cz/read.php
?142,2305614

Odpovědět na příspěvek

RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: OC Muž

Založeno: 08.11.2007, 12:27

V čem programovat je dost zřejmé, jak píši na www.ocs.cz:

"There is a lot of programming environments one can use: there is BASIC, actually quite ugly and inconvenient, but for many of us, the first thing–so far as programming is concerned–we learnt. There still are such things as the assembly language, front panels, or real men (who, as widely known, don't eat quiche).

Well, I've been there, done that... so many times. I've learnt BASIC and the machine code of a handful of different processors, from the famous oldtimers IBM 360/370 through Zilog Z80 to the Motorola 68k family or the PPC beasts of nowadays. I've used such beasts as Algol, Cobol, Simula 67, or Lisp. I've tried Smalltalk and Prolog and love them still, though they are hardly practically useable. I've wrote my share of Pascal, Modula, and C++ lines. Heck, I've even truly used a front-panel of some pretty ancient HP machine. Being a WebObjects programmer, naturally I use Java every day (oh, Java! The blazing speed of Smalltalk, along with the simple elegance of C++!).

To sum it all up: if I am stuck now–more or less–with Objective C and Cocoa, it means only one thing: it is the most powerful and convenient thing I've seen so far. That's all."

Stran další diskuse -- omlouvám se, leč nemám na to pokdy (nechodím momentálně ani na Okoun :( ). Chcete-li, napište do té diskuse, že OC si je velmi jist, že neexistuje nic srovnatelně silného a pohodlného jako Cocoa/ObjC :)

Odpovědět na příspěvek

RE: RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: kirsten Muž

Založeno: 08.11.2007, 12:33

to je sice pravda, ale jak jsem psal dole, je potreba se starat o byznys a ne si jen tak programovat pro radost. z tohoto pohledu jsou veskere vase prispevky vice nez usmevne....

Odpovědět na příspěvek

RE: RE: RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: OC Muž

Založeno: 08.11.2007, 12:40

No, můj bankovní ředitel si nestěžuje :)

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: kirsten Muž

Založeno: 08.11.2007, 12:46

to vam samozrejme nikdo nebere a budiz vam to prano. ale co z toho, daji se pouzit wo na aplikacnim serveru? daji se pouzit na 99% pouzivanych desktopu? samozrejme ze bych byl rad, kdyby to tak bylo, ale pravda je takova, ze ne. bohuzel.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: OC Muž

Založeno: 08.11.2007, 13:22

> daji se pouzit wo na aplikacnim serveru?

Nechápu otázku. WO jsou aplikační server. Nejstarší, a i přes tu nešťastnou Javu dodnes bezkonkurenčně nejlepší.

> daji se pouzit na 99% pouzivanych desktopu?

Nemyslíte náhodou Cocoa?

Ano-li, pak bohužel se v aplikačním serveru (tedy WO) použít nedá, ale jen proto, že tuto podporu -- jež existovala a byla skvělá -- Applovci odstřihli, nahradivše ji, stokráte bohužel, právě tou zatrolenou Javou :( To bylo právě v době, kdy si Apple myslel, že Java je světlá budoucnost...

A co do procenta desktopů, jediné, co lze použít na 99 %, je plain C :) Cocoa lze použít na nějakých hádám asi tak 7 % desktopů, neboť asi tolik bude asi současný podíl Mac OS X.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: kirsten Muž

Založeno: 08.11.2007, 15:46

ano, neni zadna podpora pro deployment. ale to je proste realita, kterou je potreba prijmout. to, ze je wo (jako aplikacni server) skvely je celkem k nicemu, kdyz se nikde neda udelat zadna instalace pro serverove aplikace. a s klientskymi vecmi je to podobne. bohuzel. mozna je 7% desktopu macosx, ale to neni rozhodujici. rozhodujici je poptavka, a ta se z 99% tyka pouze win desktopu. a neverim, ze nechapete jak to myslim.

Odpovědět na příspěvek

RE: RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: Satai Muž

Založeno: 08.11.2007, 15:19

Promin, ale kdys videl naposledy Javu? Ta blazing speed of smalltalk je vtipny aforismus, ale realita je pro drtivou vetsinu aplikaci nekde jinde. A v tech ostatnich se vetsinou vyplati Fortran ;)

Odpovědět na příspěvek

RE: RE: RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: OC Muž

Založeno: 08.11.2007, 21:49

Nelíbí se ten aforismus? Mám lepší: Saying JAVA is good because it works on all OSes is like saying anal sex is good because it works on all genders.

Odpovědět na příspěvek

RE: RE: Java jako nesmysl zni dost posetile

Autor: kirsten Muž

Založeno: 08.11.2007, 12:31

ad - Swing (a podobné inicativy, včetně multiplatformního AppKitu) jsou cesta do pekel. Má-li multiplatformní projekt dobře vypadat, prostě *musí* mít pro každou platformu specifické GUI.

to pak ale nebude moc multiplatformni desktop, ne? sice trochu chapu zatvrzelost oc na objc, ale je potreba delat na tom, co vydelava. predevsim.

Odpovědět na příspěvek

RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: vlk Muž

Založeno: 08.11.2007, 13:01

tady s tim bych souhlasil na 100% ... ano, dodavat platformove specificke GUI je nejoptimalnejsi varianta a asi sen a splnene prani vsech klientu, nicmene udrzovani X GUI na vsemoznych platformach i s jejich specifiky se vetsinou ukazalo (alespon pro nas) jako velice nevyhodne ... GUI ve Swing apod sice nesplnuje nejposlednejsi trendy UI (pruhledna okna, fade/zoom/docking efekty) ale funguje vicemene na vsech platformach stejne - coz setri nemaly cas i peniz ...

nicmene souhlasim, ze pro aplikaci psanou jen na konretni platformu nabizi C# nebo XCode vetsi komfort

Odpovědět na příspěvek

RE: RE: RE: RE: Java jako nesmysl zni dost posetile

Autor: Satai Muž

Založeno: 08.11.2007, 15:07

Swing samozrejme tyhle efekty umi, ale malokdo je pouziva, protoze podpora neni dvakrat pohodlna ;( Daleko lepsi varianta bude (doufejme) za par mesicu hotova JavaFX. Do te doby zustanou Swing i SWT ve vetsine pripadu omezene hlavne na GUI k enterprisovym aplikacim. (Na druhou stranu mozna dost z vas pouziva Javovska GUI, aniz by to tusila, trebas Azureus...)

Odpovědět na příspěvek

RE: RE: Java jako nesmysl zni dost posetile

Autor: maja Muž

Založeno: 08.11.2007, 13:42

A preco ich "srovnavat" ? To su to object-oriented jazyky a prostredia nie je dovod - jedno je urcene a vyhovuje inym potrebam ako druhe.
Pochovat Java bridge je poriadna blbost, o pouzivani Eclipse+WOLips ani nehovorim - cisty alibizmus a uspora penazi. Odporucam nakodit v tom nejaku "realnu" WO aplikaciu - masochizmus.

Odpovědět na příspěvek

IDE

Autor: Satai Muž

Založeno: 08.11.2007, 15:04
Odpovědí: 0

Nechci tu byt za kverulanta, ale kdyz jsem naposledy pouzival IDEs od Apple, tak staly za starou backoru. Objective C je fain jazyk, ale trpi podobnym neduhem jako Ruby - co se nazene na jazyku ztrati programator v podpore nastroju. Kdo je zvykly na veci jako silne refactoringy nebo schopne generatory kodu, tak dost ostrouhal. Jak to vypada dnes?

Odpovědět na příspěvek

RE: IDE

Autor: OC Muž

Založeno: 08.11.2007, 21:29

Stran generátorů kódu -- to je hodně velký nesmysl. Rozumně navržený systém se generovanému kódu vyhýbá jak čert kříži. V Cocoa dávalo smysl v podstatě jediné, totiž generování accesorů -- a to, chválabohuzetydary, odstranilo ObjC 2.0.

Stran refactoringu máte do značné míry pravdu, ten v Xcode hodně chyběl. Xcode 3 obsahuje nějaké první vlaštovky; sice to pořád není to, co bylo před deseti lety ve Smalltalku, ale lze se nadít, že se to bude zlepšovat :)

Odpovědět na příspěvek

RE: RE: IDE

Autor: Satai Muž

Založeno: 09.11.2007, 12:50

Generatory kodu jsem samzorejme nemyslel trebas antscripty generujici ze zdrojaku dalsi zdrojaky, tohle obdobi uz ma Java nastesti diky anotacim davno za sebou. Myslim tim sitauce typu: mam beanu, chci konstruktor s temito jejimi poli. Mam beanu a chci hashchode, ktery vraci tato pole. Slusna IDE tohle resi na par stisku kalvesnice, nedovedu si predstavit, ze bych psal trebas inicializacni metody rucne.

Odpovědět na příspěvek

apple tech talk

Autor: goddard Muž

Založeno: 08.11.2007, 15:29
Odpovědí: 0

@oc: budete na apple tech talk v praze? docela rad bych si tam promluvil s lidmi co uz v objc nejaky ten patek delaji (hroch32, jj a dalsi)

Odpovědět na příspěvek

RE: apple tech talk

Autor: OC Muž

Založeno: 08.11.2007, 21:24

Obávám se, že nikoli :(, je mi líto, leč v poslední době frapantně nestíhám :(

Odpovědět na příspěvek

Java

Autor: Algi Muž

Založeno: 08.11.2007, 16:21
Odpovědí: 0

Pane Čada. Jestli se Apple opravdu vykašle na Javu a nenechá to dělat ani Sun, pak si odřízne cestu do sféry enterprise aplikací. Opravdu si nedokážu představit, že by někdo dělal web services v PHP, natož pak v Objective-C.

Jazyk je to sice hezký, ale webové aplikace se v něm opravdu nedělají. Neříkám, že to nejde, ale nejsou na to vůbec žádné knihovny! Já chápu, že vás tvorba enterprise aplikací v Javě neživí, ale mě ano. A pokud by Apple skončil s Javou, tak já bych musel chtě nechtě skončit s Applem. Můžu vám také rovnou říct, že bych nebyl sám. Se mnou by totiž odešlo dalších pár tisíc vývojářů, co vyvíjí aplikace v Javě na Mac OS X.

Ale jistě, komu záleží na těch ubohých Javistech. Vždyť Objective-C je přece lepší! Akorát v něm nikdo nepíše enterprise aplikace, ale to je Applu jedno. Ten má svůj iPhone a ten určitě vydělává více.

To jenom tak na okraj, abyste si nemyslel, že nikdo Javu na Mac OS X nepoužívá a všem že je ukradená. Smutný to konec...

Odpovědět na příspěvek

RE: Java

Autor: wessan Muž

Založeno: 08.11.2007, 17:22

jj ... souhlas. Enterprise sektor je dnes prakticky cely postaveny na Jave (language level security ma prece jen dost velky prakticky dopad). A predstava, ze bych mel vyvijet aplikace v Objective-C bezici jen na Mac OS X, protoze Apple neni schopnen/ochoten dodat JDK/JRE, je dost neprijemny a radsi budu delat pro Windows+Linux.
Ja osobne jsem chtel taky prejit na OS X a cekal jsem na Leoparda, takhle zustavam na Windows. Nejvic mi vadi necitelna politika Apple, kdy vsechno utajuje. Byl bych radsi, aby rekl, ze Java 6 na OS X nebude a dal moznost ji delat nekomu jinemu.

Odpovědět na příspěvek

RE: RE: Java

Autor: OC Muž

Založeno: 08.11.2007, 18:34

v ObjC se enterprise aplikace vyvijeji *nesrovnatelne* lepe, nez v te hruze. Vyzkousel jsem -- temer jiste na rozdil od Vas -- oboje, takze mohu srovnavat (nebo Vy mate s vyvojem enterprise v ObjC zkusenosti?)

Odpovědět na příspěvek

RE: RE: RE: Java

Autor: wessan Muž

Založeno: 08.11.2007, 18:46

Nemam zkusenosti s vyvojem v ObjC, ale kdyz mi ukazete lakave zdroje (existujici frameworky apod.) a odkazy na to jak vyvijet aplikace, ktere pobezi vsude od OS X Server, pres Solaris, LInux az po Windows, tak bych to mohl zvazit.
Taky by me zajimalo jake vyvojove prostredi pozivate, protoze s XCode 2.0 jsem mel tu cest a je to fakt des a hruza proti modernim IDE.
Jen informacne: jak dlouhe a jak hluboke zkusenosti mate s obojim a kde vidite hlavni rozdily, at jen nemluvite do vetru.

Odpovědět na příspěvek

RE: RE: RE: RE: Java

Autor: OC Muž

Založeno: 08.11.2007, 21:20

Bohužel v současnosti v ObjC (enterprise) aplikace vyvíjet nelze, vinou zaslepené a hloupé orientace Apple na Javu.

Pro zajímavost: dokud WebObjects podporovaly ObjC, prodávaly se za $50 000 licence -- a prodávaly se skvěle. Vinou Javy a jen Javy se propadly na okraj zájmu, ačkoli stojí $500.

Jen informačně -- cca 12 let. Rozdíly jsou právě v tom, že Java je oproti ObjC nesmírně nepohodlná, prodlužuje několikanásobně práci, a zvyšuje dost podstatně pravděpodobnost chyb.

Namátkou: ačkoli se metody tříd ("statické") dědí, nelze v nich použít this jako odkaz na třídu, takže nelze nijak zjistit, ze které třídy se implementace používá; nadto se dědí (v terminologii C++) "nevirtuálně", což je strašlivé zlo, jež jde přímo proti zapouzdření a vnáší extrémně vysokou pravděpodobnost chyb. Nepoužijeme-li reflection, není Java dostatečně dynamická pro implementaci většiny rozumných služeb. Použijeme-li reflection, je zvířecky pomalá. A řadu věcí nelze v Javě rozumně udělat ani s reflection (namátkou DO či HOM).

Odpovědět na příspěvek

RE: RE: RE: RE: RE: Java

Autor: Daniel Kvasnicka Muž

Založeno: 06.08.2008, 10:37

Nemuzu si pomoci, ackoliv je toto velice stara diskuse, musim zareagovat na jeden totalni blabol: "Bohužel v současnosti v ObjC (enterprise) aplikace vyvíjet nelze, vinou zaslepené a hloupé orientace Apple na Javu."

Jakou vinu v tomhle asi tak muze mit Apple?? Kdyz je ObjC tak dokonaly, tak proc nikdo nevytvoril zadne prostredi, ve kterem by se daly webove aplikace poradne psat? Jak by mu to Apple mohl zakazat? Proste si priznejte jedno: lide v ObjC webove aplikace psat NECHTEJI. Kdyby chteli, existoval by na to ekosystem nastroju i bez pozehnani Applu (a ten by se pak treba pridal, kdyz by videl, ze je zajem).

V Jave take muzu dneska psat aplikaci a jedine, co k tomu od Sunu potrebuju, je ta Java. Zadnou "orientaci".

Bud jste si spletl samotne ObjC s verzi WebObjects pro ObjC nebo vam vas anti-Java fanatismus uz totalne zaslepil oci.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: Java

Autor: OC Muž

Založeno: 06.08.2008, 13:07

Komukoli, kdo se obtěžuje přečíst více než prvý odstavec, je zcela zřemé, že zde píši _zcela explicitně_ právě o WebObjects/ObjC.

Odpovědět na příspěvek

RE: RE: RE: Java

Autor: Iwan Muž

Založeno: 08.11.2007, 20:41

Můžete mít 100x pravdu, že ObjC a Applovský framework jsou lepší. Potíž je, že za ním stojí jediná firma. Žádný velký zákazník by do této technologie nezainvestoval. Už to vidím jak pánové z poradenské firmy najmuté zákazníkem označí produkt postavený na tomto jako nestandardní a nasazení za riskantní.

Odpovědět na příspěvek

RE: RE: RE: RE: Java

Autor: OC Muž

Založeno: 08.11.2007, 21:22

Potíž je jinde -- jmenovitě v tom, že nevíte o čem mluvíte :)

Za původními WebObjects, v době, kdy ještě podporovaly Objective C, stále jediná firma -- a firma podstatně menší, než dnešní Apple, totiž NeXT.

Velcí zákazníci stáli tehdy frontu na to, aby mohli do té technologie investovat. A to stála licence $50 000.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: Java

Autor: wessan Muž

Založeno: 08.11.2007, 22:30

TO jsou casy davno minule. Dneska by tam tezko nekdo stal.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: Java

Autor: kirsten Muž

Založeno: 09.11.2007, 14:24

presne tak. k cemu to je dobry, kdyz v objc neprodate jedinou instalaci. ani na serverove aplikace ani na desktopove. muze byt 100x vsechno pravda a po pravde ze svy zkusenosti bych radeji delal v objc nez v jave, ale kvuli tomu zadny rozumny clovek nepusti kseft nekomu jinemu. bud se prizpusobite a delate v jave, nebo to bude delat nekdo jiny.

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: RE: Java

Autor: OC Muž

Založeno: 09.11.2007, 15:07

Zaspal jste dobu přibližně o deset let :)

Zhruba takto argumentovali zastánci přechodu od ObjC k Javě v Apple před deseti lety. Od té doby pochopili, že opak je pravdou: v Javě napsané aplikace jsou (v průměru) tak mizerné, že je koupí málokdo; nativní aplikace naopak zákazníci kupují, neboť fungují (v průměru) výtečně. (Při vynaložení srovnatelného úsilí na straně programátorů, a tedy také při srovnatelné ceně, samozřejmě.)

Teď jen ještě aby jim došlo, že totéž platí pro enterprise, a vrátili WebObjects/Objective C....

Odpovědět na příspěvek

Java

Autor: wessan Muž

Založeno: 08.11.2007, 17:08
Odpovědí: 0

Java v XCode podle me vubec nema vyznam. Na Javu existuji daleko lepsi prostredi, takze nemyslim, ze by nekdo z Java programatoru lezl do XCode. Prece jenom IntelliJ IDEA je peknych par let pred XCode. Sice neco stoji, ale za ten luxus se to vyplati. Myslim, ze i Netbeans a Eclipse na tom budou porad lepe nez XCode.

Co mi vadi a co je stopka pro mnoho vyvojaru, je absence JRE/JDK 6 v Leopardu, ktera nabizi daleko lepsi integraci se systemem obecne. Na windows prakticky nepoznate rozdil mezi Java aplikaci (pokud pouzije nativni skin) a ostanimi aplikacemi. Jestli na OS X vypada jinak, tak ji proste Apple nedokazal dobre integrovat.

Ad java rychlost: Mozna by bylo dobre najit si nejake obsirnejsi testy, ale vykon Java/C je zhruba stejny a spis se lisi podle zpusobu uziti a pouzite JVM. Pokud nekdo pusti aplikaci a zapocita do casu i cas straveny class loadingem je na tom hur Java. Ale kazda trida se nacita jednou (muze i vickrat, ale neni to obvykle) a pak bezi srovnatelne rychle. Uvazujte sami jak casto spoustite aplikcaci k pomeru casu, ktery bezi.

K tomu vykonu si doporucuju najit testy s novymi JVM. Ukazuje se, ze optimalizace na velikost cache, dynamicky inlining, blizkost souvisejicich dat na heapu (maly cache miss) je dost velkou vyhodou proti C a je docela mozne, ze s pridanim alokace objektu primo na stacku (planovane na JVM7 nebo 8), uz budou testy vyznivat dost zalostne pro C.

Odpovědět na příspěvek

OC Fidel Castro

Autor: gazda Muž

Založeno: 08.11.2007, 20:40
Odpovědí: 0

Som dlhorocny J2EE vyvojar, ktoreho Tiger pritiahol do Mac sveta. Citim sa tu skvele a Mac OS X je skvely system pre vyvoj v jave. Rad by som reagoval na dnesny java atak od pana Cadu, ktory mi pripadal ako boj Fidela Castra proti zlemu imperializmu.

1. Svetu podnikovych technologii vladne IBM, Oracle, SUN, Microsoft. Trh vyniesol Javu na 1.miesto a jej spochybnovanie iba vyvolava usmev.

2. Ako Mac user a programator citim povinost naucit sa Objective-C + Cocoa kniznice aspon na zakladnej urovni. Pan Cada, vzhladom na to aky Ste fanaticky stupenec tejto technologie, tak Vas serial /Nastal cas na Kakao / je jeden velky chaos. Cely serial je bez systemu a koncepcie a v podstate neviem pre koho je pisany. Nie som majster sveta ale 20 rokov programujem a ten kurz je pre mna nepouzitelny. Akakolvek kniha ObjectiveC/Cocoa z Amazonu je hotova basen oproti Vasmu kurzu.

Odpovědět na příspěvek

RE: OC Fidel Castro

Autor: OC Muž

Založeno: 08.11.2007, 21:10

1. Trh vynesl na prvé místo také Windoze. A jde zhruba o stejnou srajdu jako Java.

2. Dá rozum, že seriál, který vzniká postupně v průběhu několika roků, nelze srovnávat s knihou, jež je psána jako jeden celek. Vy jste toho v životě moc nenapsal, že ne?

Odpovědět na příspěvek

RE: RE: OC Fidel Castro

Autor: wessan Muž

Založeno: 08.11.2007, 21:58

bude to reakce na vic prispevku od Vas, prominte ze to pisu do jednoho

1) postaveni Windows a Javy je zcela jine, Windows mely misto na trhu relativne volne (Apple byl proste uzavreny) a jine graficke rozhrani pro tuctova PC proste neexistovalo ... Java vstupovala na trh plne obsazeny ruznymi jazyky a presto je dnes dominantni jazykem ... myslim, ze u Javy hrala roli spise jednoduchost tvorby aplikaci a spousta moznosti do te doby dost nevidane (zadne hlavickove soubory, bezela na vice systemech, rmi apod.)

2) ted nevim co je kniha a serial, nebo jestli jsem metaforu vubec nepochopil ... Java byla napsana v podstate par programatory hned na zacatku a od te doby neprodelala zadnou ideologickou zmenu (coz treba hybrid C a SmallTalku podle me prodelal) ... nejvic zmen doznala v 1.5, kde se pridaly generics a par dalsich veci, ktere ale taky nemely dopad na ideologii (i tyhle konstrukty se daji prevest na 1.4)

ad psani nepsani: delam v Jave asi 5 let, predtim jsem delal (ale jen jako hobby) v C++, mezi tim podle druhu prace jsem narazil na Flash, PHP, C#, SmallTalk ... v Jave jsem se vzdy rad vracel ... aktualne pisu v Jave diplomovou praci, jejiz vysledkem ma byt objektova DB a vzhledem k mnoha zajimavym implementacnim prvkum v teto DB muzu rict, ze znam Javu az po kazdy byte-code (doslovne) ... neni to jako kdyz pisete nejake tuctove aplikace, kde neco haflakate v UI designeru a napisete par radku kodu, nebo udelate webovou aplikaci ve Springu treba (taky bez urazky - v praci taky delam neco podobneho)

kdyz budete pristupovat ke kazdemu jazyku negativne, tak se nikdy nedostanete ze sveho ruzoveho pokojicku a nezjistite, ze neni az tak ruzovy ... ja treba dokazu pochopit, co se lidem libi na SmallTalku, ale treba pro me ty same argumenty (napr. dynamika, absence isolace, syntax apod.) jsou negativni vlastnost, to ale neznamena, ze o tom budu rikat, ze je to sracka - ma to svou myslenku, ktere se drzi ... jazyky ktere ji nemaji jsou podle me napr. PHP, C#, ActionScript (i kdyz tam se hosi z Adobe snazi) apod.

u Javy se mi libilo, ze cim hloubeji clovek jde tim si rika, jak dobre je navrzena ... muzu s vami souhlasit, ze dedicnost v Jave je spatna (sami autori rikali, ze by ji tam nedali a ze byla zhrnuta jen kvuli zvyklostem programatoru z C++) ... naptiklad v te DB co delam je kazda trida "final" a dedicnost je jen na mistech nezbytnych pro spojeni s Java API

Odpovědět na příspěvek

RE: RE: RE: OC Fidel Castro

Autor: OC Muž

Založeno: 09.11.2007, 15:05

> kdyz budete pristupovat ke kazdemu jazyku negativne

Naopak. Já k Javě přistupoval s nadšením; to vyprchalo, bohužel, na základě praxe. Odradilo mne od ní to, že je pramizerně navržená, a to, že čím hlouběji člověk jde, tím naráží na další a horší nedomyšlenosti a chyby v designu.

Už jsem psal nejen o dědičnosti, ale také o nedostatečných dynamických službách (až implementujete v Javě funkční HOM -- nevíte-li o co jde, vizte www.ocs.cz/text/HOM.html --dejte vědět). Co třeba naprosto šílená a nemožnost rozdělit implementaci rozsáhlé třídy do více nezávislých zdrojáků? A samozřejmě, absurdně neobjektový návrh knihoven (namísto logického string.intValue je tam nesmyslné Number.parseInt, a tak dále...). Takto by se dalo pokračovat předlouho....

Ono asi jde o to, odkud jste k Javě přišel; pokud z C++, jež je ještě daleko horší, samozřejmě musíte být nadšen; pokud ale z civilizovaného ObjC... je to něco jako přesednete-li do Passata z Trabanta, budete jej považovat za nejlepší auto na světě; pokud do něj však přesednete z Rollsky, jasně uvidíte jeho chyby.

Odpovědět na příspěvek

RE: RE: RE: RE: OC Fidel Castro

Autor: wessan Muž

Založeno: 11.11.2007, 19:53

Dynamika PJ - dynamicke jazyky jsou hezke na hrani, ale to je vse ... s rostoucim projektem se stavaji hure managovatelne a napriklad ActionScript se vyviji smerem od dynamickeho jazyka, protoze se ukazalo, ze na vetsi/tymove projekty je dynamika jazyka skodliva a vyrazne zpomaluje vyvoj/debugovani/testovan
i
HOM - jinak pojmenovane volani metod se semanticky stejnym vyznamem ... ano ma to syntactic sugar na nejake konstrukty, ale ze by me to nejak nadchlo to ne
nerozdelitelnost tridy do souboru - pokud mate tridu tak dlouhou, tak byste mel uvazovat jestli neni chyba na vasi strane, protoze jste pravdepodobne nekde mel udelat dekompozici, aby vam nevznikal obludne dlouhy kod ... nemluve o tom, ze usporadani soubor-trida ma zasadni vyznam pri classloadingu, coz je jeden z architektonickych skvostu Javy
"namísto logického string.intValue je tam nesmyslné Number.parseInt, a tak dále" ... to je absolutni nesmysl, pri vasem "smysluplnem podani" musi String vedet neco o tride Number, na kterou ma neco prevest ... kdybyste napriklad udelal tridu MySpecialNumber, tak prece nemuzete prepisovat String tridu a pridavat tam string.toMyFastMumber ... ale je logicke, ze pridate metodu do tridy MySpecialNumber.parseFast
Number() ... mozna byste mel zauvazovat jestli neni problem ve vasel "objektovem" mysleni a nehledat nejdriv chybu v jave ... ale timhle jste mi celkem ukazal na jake zrudnosti potrebujete dynamicky jazyk a proc je dobre, ze java takova neni
znam Javu dost dobre a pri soucasne praci se pohybuji hloubeji nez u nazvu metod a nedelitelnosti tridy do souboru, takze vim, ze slovo "sracka" ji rozhodne nepopisuje (a vami uvedene priklady se jen stezi daji nazvat jitim do hloubky) ... samozrejme java mohla byt lepsi, ale jedna se o nejlepsi jazyk na jaky jsem narazil a uz jich par bylo

Odpovědět na příspěvek

RE: RE: RE: RE: RE: OC Fidel Castro

Autor: OC Muž

Založeno: 11.11.2007, 20:26

Račte být na frapantním omylu. A je smutné (ale žel příznačné), že i mezi velmi zkušenými programátory v Javě je tolik lidí, již objektovému designu zbla nerozumějí. Inu, není divu: právě takoví Javu navrhli :)

> dynamicke jazyky jsou hezke na hrani, ale to je vse ... s rostoucim projektem se stavaji hure managovatelne

Naopak, právě s rostoucí velikostí projektu se výhoda dynamických jazyků projeví nejvíc. To není teorie; to je zcela konkrétní osobní zkušenost. Jaké jsou Vaše zkušenosti s rozsahem projektu? Mé sahají k projektu bankovního systému v rozsahu cca 800 000 zdrojových řádků -- a to právě v Objective C, jež typicky potřebuje oproti Javě cca třetinu až polovinu. Máte zkušenosti se zvládáním javského projektu o nějakých zhruba 1.5-2.5 miliónu zdrojových řádků? Ano-li, dobře víte, že to vůbec není legrace. Zvládnout ten bankovní projekt nebyl vůbec, ale opravdu *vůbec* žádný problém -- a to právě díky dynamickým vlastnostem Objective C (jež kupříkladu umožňují snadno implementovat takové věci, jako on-demand zavedení pluginu obsahujícího nějakou třídu ve chvíli, kdy libovolný jiný kód prvně služeb oné třídy použije: zkuste něco podobného implementovat v Javě! :))

Obávám se, že HOM jste vůbec nepochopil. Přečtěte si to znovu. Nic není dále od pojmu "syntaktický cukr". Syntaktickým cukrem je kupříkladu konstrukce objekt.zpráva z ObjC 2.0 (neznáte-li, bude popsána zanedlouho v tomto seriálu). HOM je naproti tomu hluboce sémantická záležitost.

Právě *proto*, aby nevznikal obludně dlouhý kód, je často třeba dělit třídy do samostatných souborů.

Ehm, z diskuse se stává fraška :))) -- jako odborník na Javu byste snad mohl vědět, že parseInt ani intValue nevracejí Number, a tedy.... blábolíte, neboť String, podporující intValue, by o Number zhola nic vědět nemusel :)

Nicméně, i kdyby: ono totiž je zcela symterické to, že v současném (hloupém) designu třída Integer musí "něco vědět" o třídě String, a to, že by třída String "něco věděla" o třídě Number -- jenže by to bylo z objektového hlediska nesrovnatelně čistší.

A samozřejmě, ve skutečně dobře navrženém objektovém jazyce, jímž bohužel Java není a nikdy nebyla, nemusí "něco vědět" ani jedna třída o druhé, neboť dobře navržený jazyk podporuje kategorie (což odpovídá i na MySpecialNumber -- nemluvě o tom, že v *civilizovaném* jazyce lze stejně dobře a snadno vytvořit MySpecialString; jen v Javě s její nebetyčnou prasárnou "final" to žel možné není).

Jistěže je problém právě v tom, že dokáži myslet objektově -- a právě proto neustále narážím na problémy v Javě, jež objektově navržena není. Excelentním příkladem je zmíněné "intValue" -- zdalipak jste se již někdy setkal s pojmem "polymorfismus"? Ten -- pro Vás, kdo žel o objektovém programování máte evidentně spíše představy nežli znalosti --, v tomto specifickém kontextu jednoznačně požaduje, aby *libovolná* třída, jejíž instance může v dobře definovaném smyslu representovat celočíselnou hodnotu, rozuměla "intValue" a právě jeho prostřednictvím tuto svou celočíselnou hodnotu polymorfně vracela.

A z hlediska volajícího kódu pak již je naprosto dokonale lhostejné, zda jde o instanci Integer, MyIngeniousInteger, String, MyBetterString, nebo třeba TextField či TableCell v GUI. Volající kód to v obecném případě ostatně vůbec neví a při korektním objektovém designu ani vědět nemá.

Stran jazyků, na něž jste narazil, inu, Objective C evidentně neznáte. Máte nějaké zkušenosti alespoň se Selfem? Nebo ne-li s dosti mladým Selfem, aspoň s prastarým Smalltalkem?

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: OC Fidel Castro

Autor: wessan Muž

Založeno: 11.11.2007, 21:10

Ad delka kodu:
nevim, radky se nikde v IDE nepocitaji, ale delal jsem/delam na projektech v radech tisicu trid a ze bych s tim mel problem jsem nezaznamenal ... automaticke testovani/auto inspekce kodu dela hodne ... obecne se setkavam s problemy pri tvorbe aplikaci, ale rozhodne se netykaji jazyka, ale tykaji se pochopeni prani zakaznika a jejich vykladu, navrhu architektury apod. ... pokud rikate, ze jste nemel zadny problem, tak gratuluju, jste pravdepodobne prvni programator, kteremu se neco takoveho povedlo u takove velikosti projektu
---
"v současném (hloupém) designu třída Integer musí "něco vědět" o třídě String" ... "verim", ze Javu dobre znate, ale kazda trida v Jave musi vedet o tride string kvuli metode toString() definovane v tride Object, nechapu proc by se mela zavadet i zpetna vazba (resp. cyklicka zavislost)
---
jež kupříkladu umožňují snadno implementovat takové věci, jako on-demand zavedení pluginu obsahujícího nějakou třídu ve chvíli, kdy libovolný jiný kód prvně služeb oné třídy použije: zkuste něco podobného implementovat v Javě! ... tohle je vychozi chovani Javy vyplivajici primo z architektury
---
"- jako odborník na Javu byste snad mohl vědět, že parseInt ani intValue nevracejí Number, a tedy" ... pouzil jsem stejne nazvy metod jako vy, abych nematl a zustal u stejneho prikladu, ktery jste uvedl ... vzhledem k logice veci jsem nepovazoval za nutne resit takove smesne detaily
---
jinak u toho "intValue" nejde jen o prevod na cisla, string muzete prevadet na datum, adresu, souradnice a nespocet dalsich veci ... mit toDate, toAddress, toCoordinates metodu ve stringu na prevod do vseho co muze byt stringem vyjadreno je totalni designovy nesmysl
---
" aspoň s prastarým Smalltalkem" ... ano setkal a delal jsem v nem, nastesti je to doba davno minula
---
"snadno vytvořit MySpecialString; jen v Javě s její nebetyčnou prasárnou "final" to žel možné není" ... podle poslednich trendu v OO by vsechny tridy mely byt final, protoze dedicnost je uz nejakou dobu povazovana za prekonanou dekompozici, takze pokud chcete vlastnosti stringu s jinou implementaci muzete pouzit interface CharSequence, ktery je implementovan stringem ... final u Stringu je taky celkem podstatny k zajisteni spravneho chovani vestavenych komponent a zabranuje implementaci, ktera by byla spatna a mohla zpusobil nestabilitu aplikace ... kdybyste vedel o jave i neco vic, nez nazvy nekterych metod, urcite byste nasel i dalsi duvody, proc by mel byt final

Odpovědět na příspěvek

RE: RE: RE: RE: RE: RE: RE: OC Fidel Castro

Autor: jirka Muž

Založeno: 13.11.2007, 10:36

Možná už také tušíte, že debatovat s tímto "frapantním" narcisem je ztrátou času ;)

Odpovědět na příspěvek

RE: RE: RE: RE: OC Fidel Castro

Autor: PH Muž

Založeno: 10.12.2007, 11:44

HOM sice nejde v Javě (nejspíše ale bude ve verzi 7), ale C# ho umí ;-)
Jinak v ObjC je jeho implementace také dost kostrbatá, a navíc to dost zpomaluje. Koncepčně je to ale pěkná věc, i když přímo převzatá z funkcionálního programování.

Odpovědět na příspěvek

 

 

Odpověď na příspěvek:

v ObjC se enterprise aplikace vyvijeji *nesrovnatelne* lepe, nez v te hruze. Vyzkousel jsem -- temer jiste na rozdil od Vas -- oboje, takze mohu srovnavat (nebo Vy mate s vyvojem enterprise v ObjC zkusenosti?)


Jméno:

Pohlaví:

,

E-mail:

Předmět:

Příspěvek:

 

Kontrola:

Do spodního pole opište z obrázku 5 znaků:

Kód pro ověření

 

 

 

 

Nejčtenější články
Nejlépe hodnocené články
Apple kurzy

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: