<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">&gt; &nbsp;&gt;&gt;&gt; class str(str):<br>
&gt; ... &nbsp; &nbsp; def zzzmojefce(self):<br>
&gt; ... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return &quot;blabla&quot;<br>
&gt; ...<br>
&gt; &gt;&gt;&gt; str().zzzmojefce()<br>
&gt; &#39;blabla&#39;<br>
&gt; &gt;&gt;&gt; &quot;xxx&quot;.zzzmojefce()<br>
&gt; Traceback (most recent call last):<br>
&gt; &nbsp; File &quot;&lt;stdin&gt;&quot;, line 1, in &lt;module&gt;<br>
&gt; AttributeError: &#39;str&#39; object has no attribute &#39;zzzmojefce&#39;<br>
&gt;<br>
&gt; Protoze standardni chovani by samozrejme bylo:<br>
&gt;<br>
&gt; &gt;&gt;&gt; class nakatrida():<br>
&gt; ... &nbsp; &nbsp; def fce1(self):<br>
&gt; ... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return &quot;nazdar1&quot;<br>
&gt; ...<br>
&gt; &gt;&gt;&gt; class nakatrida(nakatrida):<br>
&gt; ... &nbsp; &nbsp; def fce2(self):<br>
&gt; ... &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return &quot;nazdar2&quot;<br>
&gt; ...<br>
&gt; &gt;&gt;&gt; nakatrida().fce1()<br>
&gt; &#39;nazdar1&#39;<br>
&gt; &gt;&gt;&gt; nakatrida().fce2()<br>
&gt; &#39;nazdar2&#39;<br>
&gt;<br>
&gt; Nebylo by tedy lepsi, aby vsechno byla class a programator alespon<br>
&gt; mohl predpokladat, ze se vsechno chova stejne? ;)<br>
<br>
</div>Však se to chová stejně, ne? Jediná chyba je, že jazyk nepoznal<br>
duplikaci názvu třídy, jinak je vše logicky postavená. </blockquote><div class="Ih2E3d"><br>&gt; *chyba* *nepoznal*&nbsp; *jinak je vse logicke*<br>... jsem rad, ze si rozumime :).<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mě přijde, že Groovy je takový &quot;truc podnik&quot; Sunu. Že je to ze stejného<br>
ranku jako &quot;ne, my nebudeme používat nic odjinud, my prostě musíte mít<br>
něco vlastního, i když je to horší, než to co existuje, a musíme a<br>
musíme a musíme&quot;. A když bychom neměli, tak bychom umřeli a rozšlapeme<br>
vám bábovičky.</blockquote><div class="Ih2E3d"><br>Ja to tak nevidim. Jednak Groovy neni vytvor Sunu (ikdyz se toho chytil a podporuje ho), ale hlavne je logickym vyustenim situace, kdy je Java vhodna na enterprise aplikace, ale neni v cem psat rychle prototypy a male nastroje.<br>
<br>V praci jsme resili problem, co dat javovskym programatorum za nastroj k prototypovani a k tvorbe malych doplnkovych aplikaci, protoze plna java je prilis velky kanon. Je snad jasne, ze ucit programatory python a deployovat ho na 100% java servery (a vyskolenou obsluhu, zajisteny support, zaplacene vyvojove nastroje) je nesmysl. Navic co s aplikaci, ktera sice vznikla jako mala, ale jeji vyznam se zvetsil? Prepsat z pythonu do javy? Dost velky overhead.<br>
<br>Prave TADY je neco-jako-groovy idealni kombinace. Vsichni jsou spokojeni. Programatori pisou ve skoro-jave, ale ma to bliz pythonu, provozaci jsou stastni, protoze se stale staraji o java aplikace a do vyvojovych, debugovacich a testovacich nastroju se jen pridaly pluginy pro groovy.<br>
<br>Z toho pohledu nevidim na groovy nic trucoidniho. Naopak, citim, ze Sun moc dobre chape vyznam skriptovacich jazyku a nechce, aby mu ujel vlak.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ok, nesouhlas je v poho. Jinak to studium je dobrý začátek pro budování<br>
vlastní banky :-)<br>
<div><div class="Wj3C7c"></div></div></blockquote><div><br>Delam v bance :-D.<br><br>Marek</div></div><br>