DAVIDOWITCH: jako v C toto je platné pokud ta proměnná existuje se stejným názvem i uvnitř volajícího scope:

{
int a;
funkce((a=1));
}

teď mě samotného zmátlo, jestli jsem tím příkladem v pythonu deklaroval proměnnou i v aktuálním scope - podívám se:

> a
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

... takže ne. výrazy předávané jako parametr funkce jsou u C součástí aktuálního scope, v Pythonu je to naproti tomu nějaká elegantní antigravitační magie.

ANT_39: Videl, nice, dik.

XCHAOS: Ono tohle Ccko vlastne neumi, co? Ja to nemam moc rad, protoze kdyz se pak snazim lustit kod a nemam naseptavac, tak poznat ze to je call na stejnou fci a ne na jinou verzi je dost neprijemny. (Musi se hodne do dokumentace)

ANT_39:
http://en.wikipedia.org/wiki/Pyrex_%28programming_language%29
http://en.wikipedia.org/wiki/Cython

.... bohužel, tohle je přesně obrácený směr. mě by se líbilo naopak do programu v C vložit fragment s Pythoní syntaxí, který by se výsledně překompiloval jako součást té aplikace. a protože python je celkově čitelnější než C, tak vlastně to co chci, je něco jako precompiler z Pythonu do C (jenom nevidím důvod, proč by měl být do C++ ...)

samozřejmě, že vývoj který dělám teď se vůbec nevylučuje s tímhle cílem: v podstatě čím víc toho člověk umí naprogramovat v C, tak z tím většího množství "vyšších jazyků" je pak schopný udělat nějaký jednoduchý precompiler do C ...

XCHAOS: FYI: Pyrex, ani jeho naslednik Cython, nedelaj primej preklad Pythoniho zdrojaku do binarky.

XCHAOS: Tak muzes to psat nejakym tim subsetem pythonu a prelozit to do C++.

ANT_39: ...si říkám, že nějaká možnost použít tímhle způsobem v C zdrojáku fragmenty Pythonu by právě nebyla od věci :-) a nějaký precompiler by to pak unrollnul do čistého C, a bylo by s tím méně hádek, než u těch mých maker...

ANT_39: Eh, a aby byly videt ty pojmenovany parametry :)

[frac2 setNumerator: 1 andDenominator: 5];

XCHAOS: ... a pokud je chceš uvést, musíš je tuším pojmenovat, zapoměl jsem dodat. ale můžeš pojmenovat i ty povinný.

DAVIDOWITCH: ObjC je v podstate smalltalk naroubovany na C. Jestlis nekdy videl volani funkci ve smalltalku, tak v ObjC je to hodne podobne. Nejaky nahodny priklad z google:

   Fraction *frac = [[Fraction alloc] init];
   [frac setNumerator: 1];

JACHYMKO: tak v Pythonu je to tak jako šalamounsky, že některý parametry funkcní mohou mít defaultní hodnotu, a ty jsou pak při volání nepovinný.

ovšem můžeš to tam udělat i tak, že předáš povinný parametry pojmenovaný:

>>> def funkce(a): return a
...
>>> funkce(a=1)
1

jako neříkám, že je mi Python úplně cizí, a možná bych měl rozvíjet nějaký ten Pyrex, Cython, nebo tak něco - prostě nástroje pro přímý překlad Pythoního zdrojáku do binárky, ať už via C nebo jinak. (možná precompiler z Pythonu do C by mi pro začátek získal daleko více příznivců, než moje snahy...)

Ad to "podívej se někdy na něco jinýho, než C99" - tedy, kromě "nutného zla" v podobě potýkání se s udržování prehistorických PHP skriptů (což fakt není programování) jsem se v posledních letech setkal zejména s Pythonem, SQL a JQuery (což je tedy výrazně více, než JavaScript - JQuery je vlastně svět sám pro sebe, velmi inspirativní...) - takže děkuji za optání, ale nějaké základní povědomí "jak se něco dělá jinde" snad přeci jen mám... problém je, že jsou to vyšší jazyky a nad některýma věcma se tam prostě nepřemýšlí.

REDGUY: chci jen říct, že to bude záviset na tom, jak kdo implementuje a zdokumentuje tu danou funkci: ta funkce bude dělat to, co programátor uzná za vhodné, a co je u ní bezprostředně požadováno.

XCHAOS: Nevim, field se v jave rika member variable, jestli s tim miris na web, nechces kolize jmen.

JACHYMKO: Ja uhnu hodne stranou (a zkazim si svoji peclive vybudovanou povest uzce specializovaneho doktoranda programujiciho pocitacove hry) a zeptam se prikladem z VHDL, at to pochopim. Tam je instancovani entity (plus minus autobus ekvivalent volani fci) cca takhle:
...nejakej bordel...
port map(
jmeno_promenny_uvnitr_entity0 => promenna_ve_volajicim0,
jmeno_promenny_uvnitr_entity1 => promenna_ve_volajicim1,
jmeno_promenny_uvnitr_entity2 => promenna_ve_volajicim2);

tj. je vzdycky jasne videt i ve volani co skonci v jak pojmenovany promenny (ultradulezity kdyz predavas konstantu).

Je to nejak cca tak?

REDGUY: hmm, jako že nějaký parametr třeba u funkce se musí povinně jmenovat nějak ? když s tím přijde ObjC, tak je to dobré, když mám něco povinně pojmenovaného já, tak je to špatně ? :-)

REDGUY: polovina byla spíš vlastnost zvolené koncepce, než chyba. pokud vyjdeš z premisy "složitější je vždy lepší, než jednoduché", tak ano - pak si měl v podstatě pravdu, a upozornil si "chybně jednoduchou koncepci", na několika bodech.

REDGUY: jo, u toho try { } pomocí setjmp()/longjmp() bude asi jasné, že fail() bude muset být uzavřením všech načatých paměťových kontextů, ano.. pěkně se nám to zamotává, ale holt tam bude asi nějaký globální seznam kontextů týkající se vždy aktuálního try { } - a stejně bude globální seznam těch vyjímek, aby šlo ta odchycení vnořovat. jako jednoduché to nebude.

XCHAOS: Ted si nejsem jistej jestli ti spravne rozumim. Rikas, ze funkce A, ktera si bude pro svoje pracovni ucely alokovat nejakou pamet, aniz by ji vracela ven, se nebude muset starat o to, jestli je ve forget nebo remember kontextu, protoze se o to postara funkce B, ktera ji bude volat? Nebo jsem to spatne pochopil?

a jinak ano - na thread safety asi budeme muset zapomenout. to bude až C<<2 - LOL. Takze na jedne strane rikas, ze chces delat superefektivni programy, ktere umozni provoz serveru pro tisice lidi na jedne masine a na druhe strane zcela rezignujes na multithreadovost - v dobe, kdy desktopova masina muze mit tucet threadu a bez vetsich problemu lze koupit server se stovkama hw threadu. To dava smysl. Moment. Nedava 8)

A co signaly? A setjmp/longjmp?

XCHAOS: že si prakticky nikdy nenavrhl žádnou opravu ničeho, čemu říkáš "chyba" - whoa. A ja myslel ze opravy tech bugu co jsem ti ukazoval jsou tak trivialni ze to nemusim ukazovat 8)
A "chyba" tomu rikame oba, protoze proc jinak bys to potom opravil, ze 8)

REDGUY: já bych se popravdě na základě tvého stylu diskuze a neustálého odvolávání se na iOS vůbec nedivil, kdybys měl něco společného s Dannym. jenže ten měl na NYXu vlastní login, takže je to trochu záhada.

REDGUY: bude se to dědit napříč voláním, ano. funkce NEBUDE muset začínat jedním z těhle maker - máš spoustu funkcí, které vůbec nic nealokují, a pokud ano, a pokud budeš programovat složitější projekt v prostředí, kde budou tyhle alokační zvyklosti - tak bude záležitostí volajícího, zda a kdy chce tu paměť uvolnit nebo ne (tedy např. si do forget nebo remember umístí celé volání funkce - která v naprosté většině případů nebude muset řešit, co s tím chce dělat)

a jinak ano - na thread safety asi budeme muset zapomenout. to bude až C<<2 :-)

DAVIDOWITCH: Na tohle je skvelu ObjC a obzlvast v iOSu, jak mas vlastne povinne pojmenovany parametry. Je to trochu o zvyk, ale s rozumnym IDE je to bomba na pouziti.

DAVIDOWITCH: a co ten BENNYHO field ? ten se mi líbí víc....
a "vector" se většinou vyznačuje velikostí (ovšem v geometrickém smyslu se neváže na žádný pevný výchozí bod). "field" ovšem může znamenat také "položka"...)