Przyszłość Groovy'ego
krzysztof jezyna
Jakiś czas temu bardzo zainteresował mnie groovy - może na razie nie
widzę go w zastosowaniach produkcyjnych, ale do domowych potrzeb i
niewielkich projektów nadaje się doskonale. Podoba mi się jego idea...
ale ostatnio trochę się zaniepokoiłem bo zauważyłem przypadkiem że
standard tego języka nie jest rozwijany http://jcp.org/en/jsr/detail?id=241
. Czy wiecie może dlaczego? Czy którejś z firm tak naprawdę zależy na
jego rozwoju (widziałem wsparcie do Springa... czy to coś poważnego)?
Jak wygląda jego przyszłość w odniesieniu do języków takich jak Ruby
(szczególnie JRuby), których pozycja wydaje się być coraz
mocniejsza...
Mam wątpliwości czy warto inwestować w niego swój czas... czy nie
przesunąć się w stronę JRuby...
Pozdrawiam
mario
Brzezi
> Witajcie
>
> Jaki� czas temu bardzo zainteresowa� mnie groovy - mo�e na razie nie
> widzďż˝ go w zastosowaniach produkcyjnych, ale do domowych potrzeb i
> niewielkich projekt�w nadaje si� doskonale. Podoba mi si� jego idea...
> ale ostatnio troch� si� zaniepokoi�em bo zauwa�y�em przypadkiem �e
> standard tego j�zyka nie jest rozwijany http://jcp.org/en/jsr/detail?id=241
> . Czy wiecie mo�e dlaczego? Czy kt�rej� z firm tak naprawd� zale�y na
> jego rozwoju (widzia�em wsparcie do Springa... czy to co� powa�nego)?
> Jak wygl�da jego przysz�o�� w odniesieniu do j�zyk�w takich jak Ruby
> (szczeg�lnie JRuby), kt�rych pozycja wydaje si� by� coraz
> mocniejsza...
>
> Mam w�tpliwo�ci czy warto inwestowa� w niego sw�j czas... czy nie
> przesun�� si� w stron� JRuby...
Ja tez ostatnio sie nim interesuje, i powoli zaczynam nawet wprowadzac na
produkcje,
Mysle ze w porownaniu np do JRuby, i ogolnie innych jezykow skryptowych,
Groovy ma jedna niezaprzeczalna przewage, jest zgodny z java, w springu czy
w Seamie czy w innym szkielecie aplikacji, czy po prostu w aplikacji,
mozesz wybrane klasy, gdzie prosciej bedzie wykorzystac wygde programowania
w Groovy, po prostu piszesz np. klase w growym, i potem OOTB wykorzystujesz
ja w Javie, i na odwrot, jezeli potrzebujesz aby kawalek kodu byl wydajny,
to piszesz go w javie, i OOTB korzystasz z niego w Groovym
Majac nawet juz dzialajacy produkcyjny projekt i chcac dodac do niegoo
grooviego, jedyne co musisz zrobic do dodac do classpath groovy.jar i to
tyle, piszesz kod w Groovym, kompilujesz i z poziomu aplikacji nie widzisz
roznicy czy to na prawde java czy moze jednak groovy.
Po prostu tam gdzie wydajniej pod wzgledem kogodwania jest uzyc grooviego,
uzywasz grooviego, i zamiast pisac 100 lini kodu w javie, da sie to ladniej
i czytelniej zapisac w 10 linijkach grooviego, tam gdzie potrzebujesz
wydajnosci wykonywania obliczen, stosujesz jave, dzieki temu masz dwie
pieczenie na jednym ogniu
Co do standardu, to mysle ze standard standardem, a sam jezyk bedzie sie
dynamicznie rozwijal i widze w nim na prawde dobra przyszlosc, caly czas
zwiekszaja wydajnosc, dodaja nowe funkcje, wystarczy zajrzec na
http://groovy.codehaus.org/
Mysle ze groovy to bylo idealne posuniecie, modyfikacje do jezyka Java
wprowadzane sa mozolnie, nowa wersja 7 nie przyniesie wielu oczekiwanych
zmian, na przeciw wychodzi groovy, po prostu ten jezyk wywolal we mnie
wielki SZOK, jak czytam specyfikacje i ksiazki do niego, to non stop mam
szczeke przy ziemi i oczy szeroko otwarte z wrazenia :P.
Swiadomosc ze java nie przyniesie nowych zmian, i zreszta nigdy nie da sie
jej zrobic tak zeby byla idealna, powstal pomysl Grooviego, ktory czerepie
z wielu jezykow, to co jest najlepsze, z javy, ruby, perl i jeszcze kilka
innych, obchodzac problem na okolo -> javy nie da sie zmienic, ale mozna
stworzyc nowy jezyk zgodny z java... to porostu wedlug mnie genialne
posuniecie
Jezeli ktos tutaj nie patrzyl na gooviego, to na prawde goraco polecam,
chociaz pobierznie przejrzec, ja tak zrobilem i na prawde ten jezyk wywarl na
mnie ogromne wrazenie i chwycilem haczyk, i w miare mozliwosci bede wdrazaďż˝
go tam gdzie bedzie mi go wygodniej stosowac, co przelozy sie na wydajnosc
pracy :)
Narazie jeste na etapie poznawania samego jezyka, w najblizszym czasie tez
planuje wdrozyc sie w kilka bibliotek opartych o grooviego jak i szkielety
aplikacji jak grails i gorm
Mysle ze warto.
Pozdrawiam
Brzezi
DingDong
Brzezi
Pewnie ze warto, jest wiele jezykow na ktore warto zwrocic uwage, tyko
interesujac sie tamtymi jezykami musisz zaczynac WSZYSTKO od poczatku, brak
srodowiska...
Na grooviego mozesz zdecydowac sie po jakims czasie, i mozesz go wlozyc do
istniejacej juz infrastruktury w Javie ad hoc, mozesz korzystac ze wszystkiego co
do tej pory masz jak i vice versa... :)
Moze i interesowalem sie pythonem, scala, rubym i czym tam jeszcze, ale nie
widzialem w tym sensu, bo nie mialbym jak tego wykorzystac w praktyce,
grooviego biore i wkladam do istniejacego projektu i ciesze sie z jego
mozliwosci bez zadnych zgrzytow i, zero meczenia sie z integracja, po
prostu jest zgodny z java :)
Wiem ze sie podniecam, jestem tego swiadom, ale to po prostu jest genialne
posuniecie :)
Pozdrawiam
Brzezi
mario
Brzezi całkowicie się z Tobą zgadzam. Również jestem wielkim
entuzjastą tego języka. Martwi mnie jednak to że z niewiadomych dla
mnie powodów odzew ze strony "wielkich tego świata" jest relatywnie
niewielki. JRuby jest wspierany przez Sun-a, chociaż Groovy jest
bliższy idei Javy - czy to nie jest jakiś paradoks? Możnaby się
zastanowić dlaczego tak się dzieje. Groovyego wspiera Spring - i
bardzo fanie :) - ale to jednak nie jest to samo co Sun :(... JRuby
doczekał się swego standardu, status JSRa Groovyego jest niestety
"inactive"...
fv
> mozesz go wlozyc do
> istniejacej juz infrastruktury w Javie ad hoc, mozesz korzystac ze wszystkiego co
> do tej pory masz jak i vice versa... :)
Czy m�g�by� jako� przybli�y� ten temat, albo da� jakiego� linka?
Konkretniej to dajmy na to, �e mam zmavenizowany projekt web aplikacji i chcia�bym np. zacz�� pisa�
np. jakie� utile w Groovy. Metody klasy utili mia�byby by� wywo�ywane przez istniej�cy kod Java. A
jeszcze fajniej, gdyby kod napisany w groovy m�g� implementowa� interfejsy zdefiniowane w java.
Od czego zacz��?
--
fv
Xbox gamertag: fastviper PL
Moto: Suzuki GSX 650F
Auto: Nissan Primera 2,0
Brzezi
> Brzezi wrote:
>> mozesz go wlozyc do
>> istniejacej juz infrastruktury w Javie ad hoc, mozesz korzystac ze wszystkiego co
>> do tej pory masz jak i vice versa... :)
>
> Czy m�g�by� jako� przybli�y� ten temat, albo da� jakiego� linka?
ogolnie o groovym:
http://groovy.codehaus.org/
> Konkretniej to dajmy na to, �e mam zmavenizowany projekt web aplikacji i chcia�bym np. zacz�� pisa�
> np. jakieďż˝ utile w Groovy.
To jest banalne :)
Musisz dodac do projektu tylko jara groovy.jar i to wszystkie zaleznosci,
potem w taskach kompilacji, moze jednak podam na przykladzie anta a nie
mavena, bo mawena nie znam, ale z tego co wiem analogicznie sie to robi, to
obok <javac> dodajesz <groovyc> i to wszystko, na prawde to wszytko :)
> Metody klasy utili mia�byby by� wywo�ywane przez istniej�cy kod Java.
Nic prostrzego, piszesz klase w groovy, w metodach i ogolnie wykorzystujesz
wygodne konstrukcje :) i juz, kompilujesz i masz kod w groovym w postaci
klasy "javowej" w postaci pliku .class
> A
> jeszcze fajniej, gdyby kod napisany w groovy m�g� implementowa� interfejsy zdefiniowane w java.
Nic nadzwyczajnego:
/// java:
interface Foo{
///...
}
/// groovy:
class GroovyFooImpl implements Foo{
//// ...
}
identycznie bedzie tez odwrotnie, mozesz zrobic interfejs w groovy, i
implementowac to w javie.
> Od czego zacz��?
Polecam Groovy in Action, na parwde warto przeczytac, jest tam bardzo duzo
niuansow, ktorych samemu na pewno trudno bedzie sie domyslec, groovy wymaga
dosyc odmiennego podejscia do programowania :) w groovym w wiekszym stopniu
piszesz "co" chcesz osiagnac, a nie tak jak w javie "jak" :)
Jest wiele kostrukcji i wzorcow, ktore w javie nie wystepuja, wymaga to
troche praktyki ale mysle ze warto :)
Pozdrawiam
Brzezi
mario
polecam:
http://java.sun.com/developer/technicalArticles/scripting/jruby/
http://www.infoworld.com/d/developer-world/jruby-live-after-sun-oracle-merger-engineer-says-499
a na deser coś takiego ;)
http://www.theserverside.com/news/thread.tss?thread_id=39696
mario
> troche praktyki ale mysle ze warto :)
Heh np. domknięcia (closures) dzięki którym można uniknąć pisania kodu
do iteracji kolekcji :D... a jak do tego zobaczyłem coś takiego
new File("source.txt").eachLine{linia -> print linia}
to aż się do siebie zaśmiałem :)
fv
> new File("source.txt").eachLine{linia -> print linia}
>
Fu, pachnie perlozďż˝ :(
Ostatnio widz� coraz wi�cej programist�w java wracaj�cych do skomplikowanych zapis�w i t�skni�cych
za tak� sk�adni�. Czy�by Perl powraca� z now� moc�? Return of the Perl-sith?
mario
new File("source.txt").eachLine{linia -> print linia}
czy to jest według Ciebie jest to trudny i skomplikowany zapis ;) ?
spróbuj napisać to w jednej linijce w Javie...
Michal Kleczek
A czy bycie zapisanym w jednej linijce jest jakas zaleta zapisu algorytmu?
--
Michal
Jacek Czerwinski
Ale naturalnośc wyrażenia problemu juz tak.
pikson
Tak bo ten zapis czytamy:
nowy Plik "source.txt" otwórz i każdą linię wyświetl
Dla mnie jest to zancznie bardziej czytelne.
Pozdrawiam
Tomasz Trela
Marcin Jurczuk
>
> Pewnie ze warto, jest wiele jezykow na ktore warto zwrocic uwage, tyko
> interesujac sie tamtymi jezykami musisz zaczynac WSZYSTKO od poczatku, brak
> srodowiska...
>
Nie rozumiem ?
Wszystkie języki działające na JVM integrują się bezproblemowo z javą,
są pluginy do popularnych IDE.
IMHO ostatnio sporego pędu nabiera Scala. Sam zacząłem pisać w niej
trochę aplikacji na wew. potrzeby i naprawdę po paru miesiącach
człowiek się fenomentalnie przyzwyczaja do pisania w jej stylu.
Pisanie czegoś potem w Javie to "ból".
Groovy jest przyjemnym językiem(dużo pisałem w Pythonie) ale nie
wnosi niczego lepszego jakościowo. Scala to mix (udany) koncepcji z
Haskella,Erlanga,Rubiego i Javy.
Kilka udanych dużych wdrożeń napisanych w Scali zaczyna go rozkręcać
vide:
- message engine w Twitterze został przepisany w Scali,
- Novell Puls (http://www.novell.com/products/pulse/) - idea podobna
do Goole Wave - warto zobaczyć :)
- Siemens ESME,
- Sony Pictures Imageworks tier-middleware w Scali
- Nature Magazine (www.nature.com) używa Scali to tworzenia REST'owych
API,
- Électricité de France Trading (największy Francuski dostawca
energii) przepisał ponad 300k lini kodu z Javy na Scalę w swoich
aplikacjach,
Przerzucenie się jest trochę ciężkie - ale w/g mnie warto - ciekawy
powiew świeżości w świecie JVM :)
Marcin Jurczuk
W Scali:
import scala.io.Source.fromFile
fromFile("source.txt").getLines.foreach(println)
lub
fromFile("source.txt").getLines.foreach(println _)
lub
fromFile("source.txt").getLines.foreach(l => println(l))
Dobry kod to taki co jest i którki i czytelny.
Perlowe magiolinijkowce są koszmarne - czasem sam mam problem z
odczytaniem tego co miałem na myśli pisząc coś rok temu z pomocą
jakiegoś manuala....
Michal Kleczek
Nie bardzo widze, zeby bylo to jakos "bardziej naturalnie wyrazone" niz
dajmy na to:
import org.apache.commons.io.IOUtils;
...
for (
final LineIterator it = IOUtils.lineIterator(
new FileInputStream("source.txt"), "UTF-8");
it.hasNext();)
{
System.out.println(it.nextLine());
}
--
Michal
fv
> Dobry kod to taki co jest i kt�rki i czytelny.
> Perlowe magiolinijkowce sďż˝ koszmarne - czasem sam mam problem z
> odczytaniem tego co mia�em na my�li pisz�c co� rok temu z pomoc�
> jakiegoďż˝ manuala....
Moim zdaniem zaprzeczasz sam sobie. Jak do tej pory widzia�em wi�cej dowod�w na to, �e kr�tki kod
nie mo�e by� czytelny ni� na to, �e mo�e by�.
Oczywi�cie mo�na si� spiera� o zasady, ale fakty s� nieub�agane. Kod:
lines = fromFile("source.txt").getLines()
foreach (p in lines) {
println(p);
}
jest czytelny dla ka�dego.
A taki zapis:
.getLines.foreach(l => println(l))
juďż˝ nie.
Uwa�am, �e nie warto i�� za daleko w kierunku skracania zapis�w.
Od zapis�w typu (l => println) ju� bardzo niedaleko do (println $?).
(w sensie $? to "zmienna domy�lna, ta co ostatnio zdefiniowa�em albo sama si� zrobi�a po wywo�aniu
metody").
Michal Kleczek
> On 26 Lis, 09:46, Brzezi <brz...@gmail.com> wrote:
>> > Z jezykow, ktore bazuja na JVM warto zwrocic uwage rowniez na Scale.
>>
>> Pewnie ze warto, jest wiele jezykow na ktore warto zwrocic uwage, tyko
>> interesujac sie tamtymi jezykami musisz zaczynac WSZYSTKO od poczatku,
>> brak srodowiska...
>>
>
> Nie rozumiem ?
> Wszystkie języki działające na JVM integrują się bezproblemowo z javą,
> są pluginy do popularnych IDE.
>
> IMHO ostatnio sporego pędu nabiera Scala.
No wlasnie z ta "bezproblemowa" integracja ja mam troche problem.
Korzystajac z okazji wyluszcze go i poprosze o namiary na jakies materialy
(bo sam nie moglem znalezc) na ten temat.
Problem polega na tym, ze dla jezykow innych niz Java generowany bytecode
nie odpowiada wprost zrodlom programu (w odroznieniu od Javy, gdzie
mapowanie jest zestandaryzowane). To ma powazne znaczenie w przypadku, gdy
interesuje nas bezpieczenstwo systemu (innymi slowy - czy bytecode
wygenerowany przez np. scalac zabezpiecza przed np. niepowolanym dostepem do
prywatnych skladowych klasy?).
Wszystko jest fajnie dopoki kod:
class A {
private String password;
}
przeklada sie na taki bytecode, ze JVM (z wlaczonym verifierem, z
SecurityManagerem i odpowiednia Security Policy) pilnuje, ze zaden inny
fragment kodu nie dostanie sie do skladowej password obiektu klasy A.
Natomiast scalac generuje jeszcze cala mase kodu z dolarkami (dodatkowe
klasy/metody) - jaka mamy pewnosc, ze korzystajac z tegoz dodatkowego kodu
jakis zly czlowiek (np. preparujac swoj bytecode recznie - bez uzycia
kompilatora) nie moze sie dostac do czegos, do czego dostac sie nie powinien
moc?
To jest bardzo istotne w zastosowaniach, gdzie uruchamiamy ladowany
dynamicznie, nieznany i potencjalnie niebezpieczny kod - czy w tych
zastosowaniach mozna uzyc Scali?
--
Michal
Marcin Jurczuk
> import org.apache.commons.io.IOUtils;
> ...
> for (
> final LineIterator it = IOUtils.lineIterator(
> new FileInputStream("source.txt"), "UTF-8");
> it.hasNext();)
> {
> System.out.println(it.nextLine());
> }
>
Powinno być tak:
"chce odczytać plik"
W tak trywialnych operacjach "final", "iterator" to zbędny boiler
plate.
fromFile("source.txt").getLines.foreach(l => println(l))
się co zwracają poszczególne funkcje (czy iterator czy lista)
fromFile("source.txt") -> czytelne jak wół
getLines -> pobieraj linie (zwraca iterator)
.foreach() - wykonaj funkcję dla zwracanych parametrów.
Jednym z problemów Javy jest to, że kompilator nie potrafi się
domyślić jaki jest typ obiektu i wszędzie trzeba pisać
"LineIterator it" a powinno się "it".
W Scali możesz zaufać kompilatorowi jak i jaki jawnie zadeklarować
typ:
scala> var a = "jeden"
a: java.lang.String = jeden
scala> var b = 1
b: Int = 1
scala> var c:String = "osiem"
c: String = osiem
scala> var x:Int = 45
x: Int = 45
scala>
Javie brakuje pewnej inteligencji w tym zakresie...ale to tylko czubek
góry lodowej..
Michal Kleczek
>
>> import org.apache.commons.io.IOUtils;
>> ...
>> for (
>> final LineIterator it = IOUtils.lineIterator(
>> new FileInputStream("source.txt"), "UTF-8");
>> it.hasNext();)
>> {
>> System.out.println(it.nextLine());
>> }
>>
> To co napisałeś jest jak najbardziej czytelne ale jest "przegadane"
Nie bardzo rozumiem, co to znaczy "przegadane" i czy to jest wada, czy
zaleta :)
> Powinno być tak:
> "chce odczytać plik"
Zrob sobie funkcje "readFile(String fileName)" i uzyj jej. Tworzenie funkcji
jest rewelacyjnym i b. prostym sposobem poprawiania czytelnosci kodu. Aha -
i jest wspierane przez Jave.
> W tak trywialnych operacjach "final", "iterator" to zbędny boiler
> plate.
Dlaczego?
Zreszta - patrz wyzej.
> fromFile("source.txt").getLines.foreach(l => println(l))
> To jest i czytelne (podobnie jak twój kod) i zwięzłe i nie przejmuje
> się co zwracają poszczególne funkcje (czy iterator czy lista)
> fromFile("source.txt") -> czytelne jak wół
> getLines -> pobieraj linie (zwraca iterator)
> .foreach() - wykonaj funkcję dla zwracanych parametrów.
>
> Jednym z problemów Javy jest to, że kompilator nie potrafi się
> domyślić jaki jest typ obiektu i wszędzie trzeba pisać
> "LineIterator it" a powinno się "it".
To sie nazywa "nominal typing" i IMHO pozwala na unikniecie wielu bledow.
To, co ty uwazasz za zalete, jest IMHO wada - wprawdzie pozwala skrocic
zapis, ale zwieksza prawdopodobienstwo wystapienia bledow typu "WTF" (czyli
patrzymy na kod i ni cholery nie wiadomo, dlaczego on robi to cos, co robi,
a nie to co jest napisane).
>
> Javie brakuje pewnej inteligencji w tym zakresie...ale to tylko czubek
> góry lodowej..
Java rzeczywiscie nie ma wielu zaawansowanych mechanizmow. Natomiast wcale
nie jestem pewny czy to sa "braki".
--
Michal
Brzezi
>> Pewnie ze warto, jest wiele jezykow na ktore warto zwrocic uwage, tyko
>> interesujac sie tamtymi jezykami musisz zaczynac WSZYSTKO od poczatku, brak
>> srodowiska...
>>
>
> Nie rozumiem ?
> Wszystkie j�zyki dzia�aj�ce na JVM integruj� si� bezproblemowo z jav�,
> sďż˝ pluginy do popularnych IDE.
Ja wiem ze sie integruja, tylko chodzi wlasnie o wlasciwie brak
integracji, Do istniejacego juz projektu w Javie, mozesz dodac kawalki
kodu(klasy) napisane w groovym, i nic nie trzeba integrowac, po prostu jest
to przezroczyste, korzystasz z klas groovowych tak jakby to byly klasy
javowe, nie ma to znaczenia
W przypadku scali nie jest to takie trywialne:
http://jim-mcbeath.blogspot.com/2008/07/mixing-java-and-scala.html
Poza tym patrze na to w pryzmacie moich zastosowan, groovy pomoze mi w
wielu zastosowaniach cos prosciej i szybciej zaprogramowac, i nie musze go
integrowac, dziala OOTB, mozna go nawet okreslic, ze jest to "java z
przyszlosci", tylko ze rozwoj javy jest toporny, a groovy obchodzi problem
z boku, mamy niemal jave, tylko ze bardziej wygodnie i z konstrukacjami
ktorych od dawna brakuje.
Scla tez jest bardzo interesujaca, nie przecze, wrecz moge potwierdzic :)
tylko zastosowanie jej duzo bardziej zlozone.
Chociaz dzieki Twojemu postowi przyjrze sie jej jeszcze blizej, jak skoncze
swoje zapoznawanie z Groovym, zapewne zaczne poznawac scale, bo zawsze
facynowaly mnie funkcyjne jezyki :) ale kilka lat temu mialem tylko mala
stycznosc z Camlem
> IMHO ostatnio sporego p�du nabiera Scala. Sam zacz��em pisa� w niej
> troch� aplikacji na wew. potrzeby i naprawd� po paru miesi�cach
> cz�owiek si� fenomentalnie przyzwyczaja do pisania w jej stylu.
> Pisanie czego� potem w Javie to "b�l".
>
w takim razie tez musze sprobowac Scale
> Groovy jest przyjemnym j�zykiem(du�o pisa�em w Pythonie) ale nie
> wnosi niczego lepszego jako�ciowo. Scala to mix (udany) koncepcji z
> Haskella,Erlanga,Rubiego i Javy.
Grovy tez jest udany mix jezykow i koncepcji z javy, rubiego, perla,
pythona i pewnie jeszcze kilku, wybiera to co jest najlesze, dodaje to
czego brakuje w javie :) wedlug mnie wlasnie to jest cos nowego co wnosi :)
Pozdrawiam
Brzezi
Marcin Jurczuk
W przypadku Scali nie - kompilator wypluje kiedy mu się typy nie
zgadzają w stylu:
error: type mismatch
found: String
required: Int
in cache.put(key, value)
lub wyrzuci warninga jak gdzieś potrzebne jest rzutowanie typów bo
_mogą_ wystąpić problemy.
Dodatkowo jest Klasa Option - coś co rozwiązuje sporo problemów,
głównie nullPointerExeption - warto poczytać:
http://blog.lostlake.org/index.php?/archives/50-The-Scala-Option-class-and-how-lift-uses-it.html
>
>
> > Javie brakuje pewnej inteligencji w tym zakresie...ale to tylko czubek
> > góry lodowej..
>
> Java rzeczywiscie nie ma wielu zaawansowanych mechanizmow. Natomiast wcale
> nie jestem pewny czy to sa "braki".
Oczywiście nie są to poważne braki lecz bardziej "irytujące". A
uważam,że programowanie nie powinno być "nudne".
W Scali pisze się po prostu "przyjemnie".
Problemem tego jezyka jest to, że jego składnia w pewnych miejscach
jest "dziwna" (na początku - potem bardzo naturalna).
To, że jednocześnie można pisać kod imperatywnie i funkcyjnie też na
początku nie pomaga, ale z czasem trudno bez tego się obejść :)
Mam kolegę programującego i w Javie i w Lispie - w Javie zarabia w
Lispie ma przyjemność programowania (i też czasem zarabia)
IMHO Scala ma szanse połączyć takie dwa typy potrzeb w jedną.
Oczywiście potrzebne jest wsparcie mainstreamu ..
zobaczymy za 2-3 lata - czy język osiągnie masę samowystarczalności -
na razie jest na najlepszej drodze, a osoby stojące za tym językiem
przemawiają za tezą, że się uda
Pozdrawiam,
Brzezi
> On 27 Lis, 09:48, mario <mw.woj...@gmail.com> wrote:
>> > Ostatnio widz� coraz wi�cej programist�w java wracaj�cych do skomplikowanych zapis�w i t�skni�cych
>>
>> �new File("source.txt").eachLine{linia -> print linia}
>>
>> czy to jest wed�ug Ciebie jest to trudny i skomplikowany zapis ;) ?
>> spr�buj napisa� to w jednej linijce w Javie...
>
> W Scali:
> import scala.io.Source.fromFile
> fromFile("source.txt").getLines.foreach(println)
> lub
> fromFile("source.txt").getLines.foreach(println _)
> lub
> fromFile("source.txt").getLines.foreach(l => println(l))
Jezeli tak bardz chcesz w groovym tez tak mozna:
new File("source.txt").readLines().each{println it}
ale nadal wydaje mi sie prostrze i czytelniejszcze, nie mowiac juz o
wydajnosci przy duuuuuuzych plikach zastosowanie konstrukcji po prostu
new File(...).eachLine{...}
> Dobry kod to taki co jest i kt�rki i czytelny.
I taki dokladnie jest kod w groovym
> Perlowe magiolinijkowce sďż˝ koszmarne - czasem sam mam problem z
> odczytaniem tego co mia�em na my�li pisz�c co� rok temu z pomoc�
> jakiegoďż˝ manuala....
ale nie mieszaj do tego perla, bo to kompletnie inna bajka...
Pozdrawiam
Brzezi
Marcin Jurczuk
Być może moje "lubienie" Scali wynika z tego, ze spora część rzeczy
które robie to obrabianie XML'i.
Zabawa z nimi w Javie do przyjemnych nie należy.
Scala ma wbudowaną obsługę XML'a w parser jezyka co pozwala robić
takie rzeczy:
scala> class XML {
| def person(s:String) = <person><name>{s}</name></person>
| }
defined class XML
scala> var w = new XML
w: XML = XML@139491b
scala> w.person("Tomek")
res1: scala.xml.Elem = <person><name>Tomek</name></person>
scala> res1 match {
| case <person><name>{kto}</name></person> => {println("To jest "
+ kto)}
| case _ => println("Nie wiem kto ty")
| }
To jest Tomek
scala>
A to tylko najprostrzy przykład ..parsowanie XMl'i w Scali to IMHO 6-8
razy mniej kodu niż w Javie, a do tego parser Scali jest szybszy.
Pozdr,
Marcin Mielżyński
> niewielki. JRuby jest wspierany przez Sun-a, chociaďż˝ Groovy jest
JRuby juďż˝ nie jest wspierany przez Sun'a (teraz EngineYard wspiera JRuby)
> bli�szy idei Javy - czy to nie jest jaki� paradoks? Mo�naby si�
> zastanowiďż˝ dlaczego tak siďż˝ dzieje. Groovyego wspiera Spring - i
To nie przypadek �e JRuby zosta� wybrany przez Sun. JRuby mia� by�
poligonem dla wymaga� JSR-292/Da Vinci Machine w�a�nie dlatego �e jest
to j�zyk tzw: off-platform. Po za tym, Ruby jest jednym z najmniej
wdzi�cznych j�zyk�w w optymalizacji i dlatego przy jego implementacji
wysz�o najwi�cej brakuj�cych ficzer�w jakie przyda�y by si� na jvm.
Groovy to dynamizm dla ubogich, dlaczego ? Chocia�by dlatego:
remove_instance_variable :a
a = 4;lambda{}.binding.eval("a")
class Fixnum;private:+;end
Class.allocate.send(:initialize, String)
itd, itd
Ale zgoda, Groovy jest bli�szy javie poniewa� korzysta z tego samego
systemu typ�w - trudno �eby mia� gorsz� integracj� z jav� ni� JRuby.
lopex
Marcin Mielżyński
> foreach (p in lines) {
> println(p);
> }
> jest czytelny dla ka�dego.
>
Sk�d ta pewno�� ? :)
> A taki zapis:
> .getLines.foreach(l => println(l))
>
> juďż˝ nie.
>
>
Ditto
Marcin Mielżyński
>
> No wlasnie z ta "bezproblemowa" integracja ja mam troche problem.
> Korzystajac z okazji wyluszcze go i poprosze o namiary na jakies materialy
> (bo sam nie moglem znalezc) na ten temat.
>
> Problem polega na tym, ze dla jezykow innych niz Java generowany bytecode
> nie odpowiada wprost zrodlom programu (w odroznieniu od Javy, gdzie
W javie tak samo, np: niestatyczna klasa wewnętrzna nie ma odpowiednika
na poziomie jvm - trik kompilatora i tyle - podobnie pętla for dla
Iterable<T>. Domknięcia w javie również nie wymagałyby specjalnego
traktowania przez jvm.
> mapowanie jest zestandaryzowane). To ma powazne znaczenie w przypadku, gdy
> interesuje nas bezpieczenstwo systemu (innymi slowy - czy bytecode
> wygenerowany przez np. scalac zabezpiecza przed np. niepowolanym dostepem do
> prywatnych skladowych klasy?).
> Wszystko jest fajnie dopoki kod:
>
> class A {
> private String password;
> }
Scala pilnuje tego bardziej niż Java (widoczność może być nawet per
pakiet: private[foo] czy receiver - np: private[this]). Oczywiście
weryfkator jvm przy ładowaniu już tego nie zobaczy - ponieważ używa
mniej restrykcyjnych reguł. Żaden język kompilowany pod jvm nie może
złamać tych reguł.
> przeklada sie na taki bytecode, ze JVM (z wlaczonym verifierem, z
> SecurityManagerem i odpowiednia Security Policy) pilnuje, ze zaden inny
> fragment kodu nie dostanie sie do skladowej password obiektu klasy A.
>
Musi - jeśli weryfikator coś przepuszcza a nie powinien, to jest to błąd
weryfikatora.
-Xverify:none czy -Xbootclasspath/a:, -Xbootclasspath/p: używa się tylko
i wyłącznie dla szybszego startupu. Btw rt.jar ładowany jest przez
-Xbootclasspath/a:.
> Natomiast scalac generuje jeszcze cala mase kodu z dolarkami (dodatkowe
A Java nie ? (klasy wewnętrzne i anonimowe). Scala po prostu generuje
tych dolarków trochę więcej (głównie dla singletonów - MODULE$, HOFów -
to jest raczej oczywiste oraz przy manglowaniu symboli - ":" = $colon,
"+" = $plus)
> klasy/metody) - jaka mamy pewnosc, ze korzystajac z tegoz dodatkowego kodu
> jakis zly czlowiek (np. preparujac swoj bytecode recznie - bez uzycia
> kompilatora) nie moze sie dostac do czegos, do czego dostac sie nie powinien
> moc?
To samo dotyczyłoby javy - scalac nie może wyjść poza semantykę jvm.
>
> To jest bardzo istotne w zastosowaniach, gdzie uruchamiamy ladowany
> dynamicznie, nieznany i potencjalnie niebezpieczny kod - czy w tych
> zastosowaniach mozna uzyc Scali?
>
Paradoksalnie bytecode wygenerowany przez scalac można spokojnie czytać
po dekompilacji DO JAVY. Oczywiście nie jest to "idiomatic" java - ale
to nie ma nic wspólnego ze zmniejszonym bezpieczeństwem
lopex
Marcin Mielżyński
> Jakby kto� by� zainteresowany jak to wygl�da od strony JRuby to
> polecam:
>
> http://java.sun.com/developer/technicalArticles/scripting/jruby/
>
> http://www.infoworld.com/d/developer-world/jruby-live-after-sun-oracle-merger-engineer-says-499
>
>
> http://www.theserverside.com/news/thread.tss?thread_id=39696
Masz strasznie stary internet
lopex
Marcin Mielżyński
> piďż˝, 27 lis 2009 o 10:47 GMT, Marcin Jurczuk napisaďż˝(a):
>
>>> Pewnie ze warto, jest wiele jezykow na ktore warto zwrocic uwage, tyko
>>> interesujac sie tamtymi jezykami musisz zaczynac WSZYSTKO od poczatku, brak
>>> srodowiska...
>>>
>> Nie rozumiem ?
>> Wszystkie j�zyki dzia�aj�ce na JVM integruj� si� bezproblemowo z jav�,
>> sďż˝ pluginy do popularnych IDE.
>
> Ja wiem ze sie integruja, tylko chodzi wlasnie o wlasciwie brak
> integracji, Do istniejacego juz projektu w Javie, mozesz dodac kawalki
> kodu(klasy) napisane w groovym, i nic nie trzeba integrowac, po prostu jest
> to przezroczyste, korzystasz z klas groovowych tak jakby to byly klasy
> javowe, nie ma to znaczenia
>
> W przypadku scali nie jest to takie trywialne:
> http://jim-mcbeath.blogspot.com/2008/07/mixing-java-and-scala.html
>
Poniewa� scala ma wi�cej ficzer�w ni� java i groovy razem wzi�te i �aden
z nich nie jest nadmiarowy jak to ma miejsce w c++, coďż˝ za coďż˝ -
najwa�niejsze �e: klasa scali = klasa javy.
> Poza tym patrze na to w pryzmacie moich zastosowan, groovy pomoze mi w
> wielu zastosowaniach cos prosciej i szybciej zaprogramowac, i nie musze go
> integrowac, dziala OOTB, mozna go nawet okreslic, ze jest to "java z
> przyszlosci", tylko ze rozwoj javy jest toporny, a groovy obchodzi problem
> z boku, mamy niemal jave, tylko ze bardziej wygodnie i z konstrukacjami
> ktorych od dawna brakuje.
Podaj przyk�ad w kt�rym jest problem z integracj� scali i javy.
Aby m�c pretendowa� do pozycji javy przysz�o�ci Groovy musia�by wspiera�
optional static typing (a nie wspiera, pomimo �e niekt�rzy tak s�dz� -
to jest co najwy�ej multimethods).
>> Groovy jest przyjemnym j�zykiem(du�o pisa�em w Pythonie) ale nie
>> wnosi niczego lepszego jako�ciowo. Scala to mix (udany) koncepcji z
>> Haskella,Erlanga,Rubiego i Javy.
>
Scala wnosi opr�cz tego self types i structural typing - czy w innych
j�zykach jest takie co� ?
> Grovy tez jest udany mix jezykow i koncepcji z javy, rubiego, perla,
> pythona i pewnie jeszcze kilku, wybiera to co jest najlesze, dodaje to
> czego brakuje w javie :) wedlug mnie wlasnie to jest cos nowego co wnosi :)
>
Wnosi wzgl�dem javy, a o to nietrudno :)
http://www.vitarara.org/cms/why_i_chose_jruby_over_groovy
lopex
Michal Kleczek
> Michal Kleczek pisze:
>
>>
>> No wlasnie z ta "bezproblemowa" integracja ja mam troche problem.
>> Korzystajac z okazji wyluszcze go i poprosze o namiary na jakies
>> materialy (bo sam nie moglem znalezc) na ten temat.
>>
>> Problem polega na tym, ze dla jezykow innych niz Java generowany bytecode
>> nie odpowiada wprost zrodlom programu (w odroznieniu od Javy, gdzie
>
> W javie tak samo, np: niestatyczna klasa wewnętrzna nie ma odpowiednika
> na poziomie jvm - trik kompilatora i tyle - podobnie pętla for dla
> Iterable<T>. Domknięcia w javie również nie wymagałyby specjalnego
> traktowania przez jvm.
>
>> mapowanie jest zestandaryzowane). To ma powazne znaczenie w przypadku,
>> gdy interesuje nas bezpieczenstwo systemu (innymi slowy - czy bytecode
>> wygenerowany przez np. scalac zabezpiecza przed np. niepowolanym dostepem
>> do prywatnych skladowych klasy?).
>> Wszystko jest fajnie dopoki kod:
>>
>> class A {
>> private String password;
>> }
>
> Scala pilnuje tego bardziej niż Java (widoczność może być nawet per
> pakiet: private[foo] czy receiver - np: private[this]). Oczywiście
> weryfkator jvm przy ładowaniu już tego nie zobaczy - ponieważ używa
> mniej restrykcyjnych reguł. Żaden język kompilowany pod jvm nie może
> złamać tych reguł.
Ale nic nie stoi na przeszkodzie, zeby np. dla prywatnych skladowych klasy
wygenerowal pare publicznych getterow i setterow (byc moze z jakimis
dziwnymi nazwami) - verifier tutaj nic nie poradzi.
>
>> przeklada sie na taki bytecode, ze JVM (z wlaczonym verifierem, z
>> SecurityManagerem i odpowiednia Security Policy) pilnuje, ze zaden inny
>> fragment kodu nie dostanie sie do skladowej password obiektu klasy A.
>>
> Musi - jeśli weryfikator coś przepuszcza a nie powinien, to jest to błąd
> weryfikatora.
> -Xverify:none czy -Xbootclasspath/a:, -Xbootclasspath/p: używa się tylko
> i wyłącznie dla szybszego startupu. Btw rt.jar ładowany jest przez
> -Xbootclasspath/a:.
Mnie nie chodzi o bledy weryfikatora, tylko o standard translacji kodu
zrodlowego na bytecode. Chce miec pewnosc, ze kompilator nie wygeneruje
kodu, ktory z punktu widzenia weryfikatora jest jak najbardziej poprawny,
ale z punktu widzenia bezpieczenstwa - juz nie.
>
>> Natomiast scalac generuje jeszcze cala mase kodu z dolarkami (dodatkowe
>
> A Java nie ? (klasy wewnętrzne i anonimowe). Scala po prostu generuje
> tych dolarków trochę więcej (głównie dla singletonów - MODULE$, HOFów -
> to jest raczej oczywiste oraz przy manglowaniu symboli - ":" = $colon,
> "+" = $plus)
>
Java tez - tyle, ze to, co robi javac jest zestandaryzowane i robione
wlasnie pod verifier.
Ja mam taki problem, ze nie moge nigdzie znalezc _standardu_ dla Scali - w
dluzszym terminie potrzebuje wiedziec np, czy i jak to sie zmienia z wersji
na wersje.
Jak na razie w dokumentacji Scali nigdzie nie znalazlem nawet glupiego
zapewnienia, ze autorzy kompilatora o to zadbali.
[ciach]
>
> Paradoksalnie bytecode wygenerowany przez scalac można spokojnie czytać
> po dekompilacji DO JAVY. Oczywiście nie jest to "idiomatic" java - ale
> to nie ma nic wspólnego ze zmniejszonym bezpieczeństwem
Jak najbardziej ma. Jezeli autorzy kompilatora nie dbaja o wygenerowanie
bezpiecznego bytecodu, to czytajac go mozna znalezc luki w bezpieczenstwie.
--
Michal
Marcin Mielżyński
>> Scala pilnuje tego bardziej niż Java (widoczność może być nawet per
>> pakiet: private[foo] czy receiver - np: private[this]). Oczywiście
>> weryfkator jvm przy ładowaniu już tego nie zobaczy - ponieważ używa
>> mniej restrykcyjnych reguł. Żaden język kompilowany pod jvm nie może
>> złamać tych reguł.
>
> Ale nic nie stoi na przeszkodzie, zeby np. dla prywatnych skladowych klasy
> wygenerowal pare publicznych getterow i setterow (byc moze z jakimis
> dziwnymi nazwami) - verifier tutaj nic nie poradzi.
>
private dla pola w scali wygeneruje to samo co javac (co innego
protected itp - wygeneruje wtedy prywatne pola i oraz ich akcesory -
scala umożliwia zasłanianie pól)
>>> przeklada sie na taki bytecode, ze JVM (z wlaczonym verifierem, z
>>> SecurityManagerem i odpowiednia Security Policy) pilnuje, ze zaden inny
>>> fragment kodu nie dostanie sie do skladowej password obiektu klasy A.
>>>
>> Musi - jeśli weryfikator coś przepuszcza a nie powinien, to jest to błąd
>> weryfikatora.
>> -Xverify:none czy -Xbootclasspath/a:, -Xbootclasspath/p: używa się tylko
>> i wyłącznie dla szybszego startupu. Btw rt.jar ładowany jest przez
>> -Xbootclasspath/a:.
>
> Mnie nie chodzi o bledy weryfikatora, tylko o standard translacji kodu
> zrodlowego na bytecode. Chce miec pewnosc, ze kompilator nie wygeneruje
> kodu, ktory z punktu widzenia weryfikatora jest jak najbardziej poprawny,
> ale z punktu widzenia bezpieczenstwa - juz nie.
>
Nie ma czegoś takiego jak "standard translacji bytecode", nawet
kompilatory javy nie generują identycznego kodu. Po za tym, zdefiniuj
słowo "bezpieczeństwo". Z punktu widzenia popełnianych błędów czy
systemu typów lub też pilnowania widoczności, scala jest dużo
bezpieczniejszym językiem niż java.
>>> Natomiast scalac generuje jeszcze cala mase kodu z dolarkami (dodatkowe
>> A Java nie ? (klasy wewnętrzne i anonimowe). Scala po prostu generuje
>> tych dolarków trochę więcej (głównie dla singletonów - MODULE$, HOFów -
>> to jest raczej oczywiste oraz przy manglowaniu symboli - ":" = $colon,
>> "+" = $plus)
>>
>
> Java tez - tyle, ze to, co robi javac jest zestandaryzowane i robione
> wlasnie pod verifier.
Dolarki są normalnym znakiem mogącym być częścią identyfikatora -
odwracając kota ogonem - to co robi javac to jest hack :D
> Ja mam taki problem, ze nie moge nigdzie znalezc _standardu_ dla Scali - w
> dluzszym terminie potrzebuje wiedziec np, czy i jak to sie zmienia z wersji
> na wersje.
> Jak na razie w dokumentacji Scali nigdzie nie znalazlem nawet glupiego
> zapewnienia, ze autorzy kompilatora o to zadbali.
>
> [ciach]
>> Paradoksalnie bytecode wygenerowany przez scalac można spokojnie czytać
>> po dekompilacji DO JAVY. Oczywiście nie jest to "idiomatic" java - ale
>> to nie ma nic wspólnego ze zmniejszonym bezpieczeństwem
>
> Jak najbardziej ma. Jezeli autorzy kompilatora nie dbaja o wygenerowanie
> bezpiecznego bytecodu, to czytajac go mozna znalezc luki w bezpieczenstwie.
>
W takim razie tak samo nie ufałbym kompilatorom javy.
lopex
Michal Kleczek
> Michal Kleczek pisze:
>>> Scala pilnuje tego bardziej niż Java (widoczność może być nawet per
>>> pakiet: private[foo] czy receiver - np: private[this]). Oczywiście
>>> weryfkator jvm przy ładowaniu już tego nie zobaczy - ponieważ używa
>>> mniej restrykcyjnych reguł. Żaden język kompilowany pod jvm nie może
>>> złamać tych reguł.
>>
>> Ale nic nie stoi na przeszkodzie, zeby np. dla prywatnych skladowych
>> klasy wygenerowal pare publicznych getterow i setterow (byc moze z
>> jakimis dziwnymi nazwami) - verifier tutaj nic nie poradzi.
>>
>
> private dla pola w scali wygeneruje to samo co javac (co innego
> protected itp - wygeneruje wtedy prywatne pola i oraz ich akcesory -
> scala umożliwia zasłanianie pól)
>
Czy to jest gdzies wyspecyfikowane? Czy po prostu "wiadomo"...
>>>> przeklada sie na taki bytecode, ze JVM (z wlaczonym verifierem, z
>>>> SecurityManagerem i odpowiednia Security Policy) pilnuje, ze zaden inny
>>>> fragment kodu nie dostanie sie do skladowej password obiektu klasy A.
>>>>
>>> Musi - jeśli weryfikator coś przepuszcza a nie powinien, to jest to błąd
>>> weryfikatora.
>>> -Xverify:none czy -Xbootclasspath/a:, -Xbootclasspath/p: używa się tylko
>>> i wyłącznie dla szybszego startupu. Btw rt.jar ładowany jest przez
>>> -Xbootclasspath/a:.
>>
>> Mnie nie chodzi o bledy weryfikatora, tylko o standard translacji kodu
>> zrodlowego na bytecode. Chce miec pewnosc, ze kompilator nie wygeneruje
>> kodu, ktory z punktu widzenia weryfikatora jest jak najbardziej poprawny,
>> ale z punktu widzenia bezpieczenstwa - juz nie.
>>
>
> Nie ma czegoś takiego jak "standard translacji bytecode", nawet
> kompilatory javy nie generują identycznego kodu.
To prawda, ale jest np:
http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
Czy jest cos takiego dla Scali? Tzn. specyfikacja, jak konstrukcje jezyka
przekladaja sie na bytecode.
> Po za tym, zdefiniuj
> słowo "bezpieczeństwo". Z punktu widzenia popełnianych błędów czy
> systemu typów lub też pilnowania widoczności, scala jest dużo
> bezpieczniejszym językiem niż java.
Na poziomie jezyka - tak. Na poziomie bytecodu - oczywiscie nie. A
rozmawiamy w kontekscie _integracji_ roznych jezykow na JVM.
>>> Paradoksalnie bytecode wygenerowany przez scalac można spokojnie czytać
>>> po dekompilacji DO JAVY. Oczywiście nie jest to "idiomatic" java - ale
>>> to nie ma nic wspólnego ze zmniejszonym bezpieczeństwem
>>
>> Jak najbardziej ma. Jezeli autorzy kompilatora nie dbaja o wygenerowanie
>> bezpiecznego bytecodu, to czytajac go mozna znalezc luki w
>> bezpieczenstwie.
>>
>
> W takim razie tak samo nie ufałbym kompilatorom javy.
Podalem link. Kompilatory musza byc zgodne z tym, co tam jest napisane.
--
Michal
Michal Kleczek
> Marcin Mielżyński wrote:
>> Nie ma czegoś takiego jak "standard translacji bytecode", nawet
>> kompilatory javy nie generują identycznego kodu.
>
> To prawda, ale jest np:
>
> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
Aha - i oczywiscie:
http://java.sun.com/docs/books/jvms/second_edition/html/Compiling.doc.html
--
Michal
Marcin Mielżyński
>> private dla pola w scali wygeneruje to samo co javac (co innego
>> protected itp - wygeneruje wtedy prywatne pola i oraz ich akcesory -
>> scala umożliwia zasłanianie pól)
>>
>
> Czy to jest gdzies wyspecyfikowane? Czy po prostu "wiadomo"...
>
No cóż, przyznam że "wiadomo" (choć trudno tworzyć specyfikację przy
takim mismatchu pomiędzy jvm a językiem)
>> Nie ma czegoś takiego jak "standard translacji bytecode", nawet
>> kompilatory javy nie generują identycznego kodu.
>
> To prawda, ale jest np:
>
> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
Którego tak czy siak muszą pilnować się wszyscy twórcy kompilatorów pod jvm.
>
> Czy jest cos takiego dla Scali? Tzn. specyfikacja, jak konstrukcje jezyka
> przekladaja sie na bytecode.
>
>> Po za tym, zdefiniuj
>> słowo "bezpieczeństwo". Z punktu widzenia popełnianych błędów czy
>> systemu typów lub też pilnowania widoczności, scala jest dużo
>> bezpieczniejszym językiem niż java.
>
> Na poziomie jezyka - tak. Na poziomie bytecodu - oczywiscie nie. A
> rozmawiamy w kontekscie _integracji_ roznych jezykow na JVM.
>
Kod wygenerowany przez scalac może być odebrany jak kod wygenerowany
przez javac gdzie ktoś użył "specyficznego" wzorca projektowego :)
Na poziomie bytecodu scala nie jest ani mniej ani bardziej bezpieczna
niż java.
>>>> Paradoksalnie bytecode wygenerowany przez scalac można spokojnie czytać
>>>> po dekompilacji DO JAVY. Oczywiście nie jest to "idiomatic" java - ale
>>>> to nie ma nic wspólnego ze zmniejszonym bezpieczeństwem
>>> Jak najbardziej ma. Jezeli autorzy kompilatora nie dbaja o wygenerowanie
>>> bezpiecznego bytecodu, to czytajac go mozna znalezc luki w
>>> bezpieczenstwie.
>>>
>> W takim razie tak samo nie ufałbym kompilatorom javy.
>
> Podalem link. Kompilatory musza byc zgodne z tym, co tam jest napisane.
>
Nic dodać, nic ująć :D
lopex
Michal Kleczek
> Michal Kleczek pisze:
>
>>> private dla pola w scali wygeneruje to samo co javac (co innego
>>> protected itp - wygeneruje wtedy prywatne pola i oraz ich akcesory -
>>> scala umożliwia zasłanianie pól)
>>>
>>
>> Czy to jest gdzies wyspecyfikowane? Czy po prostu "wiadomo"...
>>
>
> No cóż, przyznam że "wiadomo" (choć trudno tworzyć specyfikację przy
> takim mismatchu pomiędzy jvm a językiem)
>
Wlasnie - stad moj problem. Jest bardzo realny, a mam wrazenie, ze go nie
dostrzegasz.
>>> Nie ma czegoś takiego jak "standard translacji bytecode", nawet
>>> kompilatory javy nie generują identycznego kodu.
>>
>> To prawda, ale jest np:
>>
>> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
>
> Którego tak czy siak muszą pilnować się wszyscy twórcy kompilatorów pod
> jvm.
Oczywiscie kompilatorow Javy (bo to jest Java Language Specification) -
niestety nie kompilatorow Scali.
>>
>> Czy jest cos takiego dla Scali? Tzn. specyfikacja, jak konstrukcje jezyka
>> przekladaja sie na bytecode.
>>
>>> Po za tym, zdefiniuj
>>> słowo "bezpieczeństwo". Z punktu widzenia popełnianych błędów czy
>>> systemu typów lub też pilnowania widoczności, scala jest dużo
>>> bezpieczniejszym językiem niż java.
>>
>> Na poziomie jezyka - tak. Na poziomie bytecodu - oczywiscie nie. A
>> rozmawiamy w kontekscie _integracji_ roznych jezykow na JVM.
>>
> Kod wygenerowany przez scalac może być odebrany jak kod wygenerowany
> przez javac gdzie ktoś użył "specyficznego" wzorca projektowego :)
> Na poziomie bytecodu scala nie jest ani mniej ani bardziej bezpieczna
> niż java.
Zrozum - problem polega na tym, ze piszac program w Scali chcialbym miec
pewnosc, ze wygenerowany bytecode nie zawiera dziur. Dla Javy taka pewnosc
daje mi JLS+JVMSpec - obydwie razem definiuja jak program napisany w jezyku
_Java_ zostanie zweryfikowany i wykonany przez JVM. Czy jest taka
dokumentacja dla jezyka Scala (JRuby/Groovy/whatever)?
Dla mnie to jest problem i prosze o pomoc - jezeli uwazasz, ze jest
wyimaginowany - OK, ale pomoc mi nie mozesz - dla mnie EOT w takim razie.
--
Michal
Marcin Mielżyński
> Marcin Mielżyński wrote:
>> No cóż, przyznam że "wiadomo" (choć trudno tworzyć specyfikację przy
>> takim mismatchu pomiędzy jvm a językiem)
>>
>
> Wlasnie - stad moj problem. Jest bardzo realny, a mam wrazenie, ze go nie
> dostrzegasz.
>
Problem dostrzegam, ale uważam że go wyolbrzymiasz - to tak jakby twórcy
kompilatorów w zamyśle mieli robienie dziur (których de facto nie da się
zrobić - ale to inna historia)
Jeśli semantyka języka jest inna to wystarczy być tego świadomym.
>>>> Nie ma czegoś takiego jak "standard translacji bytecode", nawet
>>>> kompilatory javy nie generują identycznego kodu.
>>> To prawda, ale jest np:
>>>
>>> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
>> Którego tak czy siak muszą pilnować się wszyscy twórcy kompilatorów pod
>> jvm.
>
> Oczywiscie kompilatorow Javy (bo to jest Java Language Specification) -
> niestety nie kompilatorow Scali.
Czegokolwiek co produkuje bytecode - nawet takiego ASM'a
>
>>> Czy jest cos takiego dla Scali? Tzn. specyfikacja, jak konstrukcje jezyka
>>> przekladaja sie na bytecode.
>>>
>>>> Po za tym, zdefiniuj
>>>> słowo "bezpieczeństwo". Z punktu widzenia popełnianych błędów czy
>>>> systemu typów lub też pilnowania widoczności, scala jest dużo
>>>> bezpieczniejszym językiem niż java.
>>> Na poziomie jezyka - tak. Na poziomie bytecodu - oczywiscie nie. A
>>> rozmawiamy w kontekscie _integracji_ roznych jezykow na JVM.
>>>
>> Kod wygenerowany przez scalac może być odebrany jak kod wygenerowany
>> przez javac gdzie ktoś użył "specyficznego" wzorca projektowego :)
>> Na poziomie bytecodu scala nie jest ani mniej ani bardziej bezpieczna
>> niż java.
>
> Zrozum - problem polega na tym, ze piszac program w Scali chcialbym miec
> pewnosc, ze wygenerowany bytecode nie zawiera dziur. Dla Javy taka pewnosc
> daje mi JLS+JVMSpec - obydwie razem definiuja jak program napisany w jezyku
> _Java_ zostanie zweryfikowany i wykonany przez JVM. Czy jest taka
> dokumentacja dla jezyka Scala (JRuby/Groovy/whatever)?
>
Jakich znowu dziur? javac też nie możesz w takim razie ufać bo może być
błąd w jego implementacji który się wymknie nawet podczas atestowania TCK.
> Dla mnie to jest problem i prosze o pomoc - jezeli uwazasz, ze jest
> wyimaginowany - OK, ale pomoc mi nie mozesz - dla mnie EOT w takim razie.
>
luzik
lopex
Michal Kleczek
> Michal Kleczek pisze:
>> Marcin Mielżyński wrote:
>
>>> No cóż, przyznam że "wiadomo" (choć trudno tworzyć specyfikację przy
>>> takim mismatchu pomiędzy jvm a językiem)
>>>
>>
>> Wlasnie - stad moj problem. Jest bardzo realny, a mam wrazenie, ze go nie
>> dostrzegasz.
>>
>
> Problem dostrzegam, ale uważam że go wyolbrzymiasz - to tak jakby twórcy
> kompilatorów w zamyśle mieli robienie dziur (których de facto nie da się
> zrobić - ale to inna historia)
> Jeśli semantyka języka jest inna to wystarczy być tego świadomym.
>
>>>>> Nie ma czegoś takiego jak "standard translacji bytecode", nawet
>>>>> kompilatory javy nie generują identycznego kodu.
>>>> To prawda, ale jest np:
>>>>
>>>> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
>>> Którego tak czy siak muszą pilnować się wszyscy twórcy kompilatorów pod
>>> jvm.
>>
>> Oczywiscie kompilatorow Javy (bo to jest Java Language Specification) -
>> niestety nie kompilatorow Scali.
>
> Czegokolwiek co produkuje bytecode - nawet takiego ASM'a
No oczywiscie nie. Pokaz mi miejsce w JLS/JVMSpec, gdzie jest mowa o np.
traits. Albo o "function value". Albo o "case class". Albo o "companion
object".
--
Michal
Marcin Mielżyński
Oczywiście że tak, kod każdego z tych języków ma odpowiednik javowy
(właśnie ta specyfikacja ogranicza te języki przed wygodną emisją bytecodu).
Trait: to jest po prostu interfejs oraz klasa ze statycznymi
implementacjami metod cechy przyjmującymi self jako pierwszy argument.
Podczas miksowania cechy do klasy - implementowany jest ten interfejs
oraz przewrapowywane są wszystkie implementacje metod cechy.
Function values/HOFs: nic innego jak instancja klasy dziedziczącej z
Function(X) z metodą apply.
Case classes: klasy które domyślnie dostają hashCode/equals/toString na
podstawie parametrów konstruktora. Użycie tej klasy w pattern matching
to zwykłe instanceof oraz posiłkowa metoda tag dla optymalizacji.
Companion object: nic innego jak singleton holder pattern.
Wszystkie te rzeczy MUSZĄ się dać wyrazić pojęciami zawartymi w
specyfikacji javy.
Na upartego mógłbyś napisać kod w javie który skompilowałby się do
identycznego bytecodu jak scala.
lopex
Michal Kleczek
> Michal Kleczek pisze:
>> Marcin Mielżyński wrote:
>>>> Oczywiscie kompilatorow Javy (bo to jest Java Language Specification) -
>>>> niestety nie kompilatorow Scali.
>>> Czegokolwiek co produkuje bytecode - nawet takiego ASM'a
>>
>> No oczywiscie nie. Pokaz mi miejsce w JLS/JVMSpec, gdzie jest mowa o np.
>> traits. Albo o "function value". Albo o "case class". Albo o "companion
>> object".
>>
>
> Oczywiście że tak, kod każdego z tych języków ma odpowiednik javowy
??? Jaki jest odpowiednik "function value" w jezyku Java? Myslalem, ze
closures to dopiero Java 7.
> (właśnie ta specyfikacja ogranicza te języki przed wygodną emisją
> bytecodu).
Przeciez pytanie nie jest "czy da sie program napisany w Scali wyrazic w
bajtkodzie JVM" - oczywiscie, ze sie da.
Pytanie jest - "w jaki sposob program w Scali przeklada sie na bytecode
JVM"?
Czy istnieje taka specyfikacja, ze przy zalozeniu, ze implementacja
kompilatora jest z nia zgodna - mozemy miec pewnosc, ze wygenerowany bajtkod
nie pozwala na dostep do prywatnych w zamysle skladowych klasy?
>
> Trait: to jest po prostu interfejs oraz klasa ze statycznymi
> implementacjami metod cechy przyjmującymi self jako pierwszy argument.
> Podczas miksowania cechy do klasy - implementowany jest ten interfejs
> oraz przewrapowywane są wszystkie implementacje metod cechy.
>
> Function values/HOFs: nic innego jak instancja klasy dziedziczącej z
> Function(X) z metodą apply.
>
> Case classes: klasy które domyślnie dostają hashCode/equals/toString na
> podstawie parametrów konstruktora. Użycie tej klasy w pattern matching
> to zwykłe instanceof oraz posiłkowa metoda tag dla optymalizacji.
>
> Companion object: nic innego jak singleton holder pattern.
>
Czy istnieje gdzies specyfikacja potwierdzajaca i _wymagajaca_ tego, co
napisales powyzej?
Niewatpliwie nie jest nia JLS/JVMSpec.
> Wszystkie te rzeczy MUSZĄ się dać wyrazić pojęciami zawartymi w
> specyfikacji javy.
>
Musza sie rowniez dac wyrazic przy pomocy maszyny Turinga - ale co to ma do
rzeczy?
>
> Na upartego mógłbyś napisać kod w javie który skompilowałby się do
> identycznego bytecodu jak scala.
jw. - co to ma dorzeczy?
--
Michal
Marcin Mielżyński
> Marcin Mielżyński wrote:
>
>> Michal Kleczek pisze:
>>> Marcin Mielżyński wrote:
>>>>> Oczywiscie kompilatorow Javy (bo to jest Java Language Specification) -
>>>>> niestety nie kompilatorow Scali.
>>>> Czegokolwiek co produkuje bytecode - nawet takiego ASM'a
>>> No oczywiscie nie. Pokaz mi miejsce w JLS/JVMSpec, gdzie jest mowa o np.
>>> traits. Albo o "function value". Albo o "case class". Albo o "companion
>>> object".
>>>
>> Oczywiście że tak, kod każdego z tych języków ma odpowiednik javowy
>
> ??? Jaki jest odpowiednik "function value" w jezyku Java? Myslalem, ze
> closures to dopiero Java 7.
Domknięcia w javie to będzie taki sam trik kompilatora jak niestatyczne
klasy zagnieżdżone - nie wymaga to zmiany maszyny wirtualnej -
prawdopodobnie będzie zrobione tak samo jak w scali (czyli pola lub refy
- dla writable closures)
>
>> (właśnie ta specyfikacja ogranicza te języki przed wygodną emisją
>> bytecodu).
>
> Przeciez pytanie nie jest "czy da sie program napisany w Scali wyrazic w
> bajtkodzie JVM" - oczywiscie, ze sie da.
>
> Pytanie jest - "w jaki sposob program w Scali przeklada sie na bytecode
> JVM"?
> Czy istnieje taka specyfikacja, ze przy zalozeniu, ze implementacja
> kompilatora jest z nia zgodna - mozemy miec pewnosc, ze wygenerowany bajtkod
> nie pozwala na dostep do prywatnych w zamysle skladowych klasy?
>
JVM tego wymaga, oczywiście można sie dostać do nich przez reflection -
ale deep reflection można zablokować security managerem - także problem
pozostaje ten sam w javie czy scali. Generalnie pole prywatne w scali
jest 1:1 z javą - nie ma żadnych akcesorów.
>> Trait: to jest po prostu interfejs oraz klasa ze statycznymi
>> implementacjami metod cechy przyjmującymi self jako pierwszy argument.
>> Podczas miksowania cechy do klasy - implementowany jest ten interfejs
>> oraz przewrapowywane są wszystkie implementacje metod cechy.
>>
>> Function values/HOFs: nic innego jak instancja klasy dziedziczącej z
>> Function(X) z metodą apply.
>>
>> Case classes: klasy które domyślnie dostają hashCode/equals/toString na
>> podstawie parametrów konstruktora. Użycie tej klasy w pattern matching
>> to zwykłe instanceof oraz posiłkowa metoda tag dla optymalizacji.
>>
>> Companion object: nic innego jak singleton holder pattern.
>>
>
> Czy istnieje gdzies specyfikacja potwierdzajaca i _wymagajaca_ tego, co
> napisales powyzej?
>
Nie musi, specyfikacja javy wystarczająco to ogranicza/wymusza, btw,
skoro specyfikacja jest taka dokładna to dlaczego różne kompilatory javy
generują odmienny kod ? - ten sam problem.
Na przykład, pętlę while w javie skompilować można na kilka różnych
sposobów i każdy jest zgodny ze specyfikacją i każdy jvm cichutko łyknie.
Rozumiem że chcesz aby istniała dokładna specyfikacja jak kod scali
mapuje się na elementy javowe (czy pośrednio/bezpośrednio na bytecode).
No cóż można taką stworzyć - community scali nie ma aż takiego wsparcia
korporacyjnego - ale jak ktoś chętny się znajdzie, to czemu nie...
Imho, z drugiej strony nie warto, pojawia się coraz więcej języków pod
jvm - java jako język już dawno zyskała sobie miano asemblera w którym
można co najwyżej napisać sterownik jdbc czy serwer aplikacyjny (wiem
przesadzone - ale coś w tym jest). Po za tym dzięki jsr-292/Da Vinci jvm
dostaje wsparcie dla ficzerów które nigdy nie będą wykorzystywane w
javie (języku) - a tylko i wyłącznie jako wsparcie dla innych (z
definicji "niewiadomojakich" języków).
lopex
Michal Kleczek
> Marcin Mielżyński wrote:
>
>> Michal Kleczek pisze:
>>> Marcin Mielżyński wrote:
>>>>> Oczywiscie kompilatorow Javy (bo to jest Java Language Specification)
>>>>> - niestety nie kompilatorow Scali.
>>>> Czegokolwiek co produkuje bytecode - nawet takiego ASM'a
>>>
>>> No oczywiscie nie. Pokaz mi miejsce w JLS/JVMSpec, gdzie jest mowa o np.
>>> traits. Albo o "function value". Albo o "case class". Albo o "companion
>>> object".
>>>
>>
>> Oczywiście że tak, kod każdego z tych języków ma odpowiednik javowy
>
> ??? Jaki jest odpowiednik "function value" w jezyku Java? Myslalem, ze
> closures to dopiero Java 7.
>
>> (właśnie ta specyfikacja ogranicza te języki przed wygodną emisją
>> bytecodu).
>
> Przeciez pytanie nie jest "czy da sie program napisany w Scali wyrazic w
> bajtkodzie JVM" - oczywiscie, ze sie da.
>
> Pytanie jest - "w jaki sposob program w Scali przeklada sie na bytecode
> JVM"?
> Czy istnieje taka specyfikacja, ze przy zalozeniu, ze implementacja
> kompilatora jest z nia zgodna - mozemy miec pewnosc, ze wygenerowany
> bajtkod nie pozwala na dostep do prywatnych w zamysle skladowych klasy?
Tak zeby nie byc goloslownym. Po prostu sprawdzilem i... dupa.
Kod w Scali:
trait SimpleTrait {
private var priv = 5;
def dupa = priv;
}
class SimpleClass extends SimpleTrait {
}
Wygenerowane klasy i ich skladowe:
interface SimpleTrait {
public int dupa();
public void traits$SimpleTrait$$priv_$eq(int arg);
public int traits$SimpleTrait$$priv();
}
public class SimpleTrait$class {
public static int dupa(SimpleTrait $this);
}
public class SimpleClass implements SimpleTrait {
//implementacja interfejsu SimpleTrait
}
Innymi slowy prywatna skladowa "priv" w trait SimpleTrait jest po
skompilowaniu upubliczniona przy pomocy pary publicznych metod:
public void traits$SimpleTrait$$priv_$eq(int arg);
public int traits$SimpleTrait$$priv();
Ze tak powiem: adios.
--
Michal
Michal Kleczek
> Michal Kleczek pisze:
>> Przeciez pytanie nie jest "czy da sie program napisany w Scali wyrazic w
>> bajtkodzie JVM" - oczywiscie, ze sie da.
>>
>> Pytanie jest - "w jaki sposob program w Scali przeklada sie na bytecode
>> JVM"?
>> Czy istnieje taka specyfikacja, ze przy zalozeniu, ze implementacja
>> kompilatora jest z nia zgodna - mozemy miec pewnosc, ze wygenerowany
>> bajtkod nie pozwala na dostep do prywatnych w zamysle skladowych klasy?
>>
> JVM tego wymaga, oczywiście można sie dostać do nich przez reflection -
> ale deep reflection można zablokować security managerem - także problem
> pozostaje ten sam w javie czy scali. Generalnie pole prywatne w scali
> jest 1:1 z javą - nie ma żadnych akcesorów.
Tak tak - wlasnie wyslalem przyklad - obejrzyj i przemysl.
--
Michal
Marcin Mielżyński
> trait SimpleTrait {
> private var priv = 5;
> def dupa = priv;
> }
>
> class SimpleClass extends SimpleTrait {
> }
>
> Wygenerowane klasy i ich skladowe:
>
> interface SimpleTrait {
> public int dupa();
> public void traits$SimpleTrait$$priv_$eq(int arg);
> public int traits$SimpleTrait$$priv();
> }
>
> public class SimpleTrait$class {
> public static int dupa(SimpleTrait $this);
> }
>
> public class SimpleClass implements SimpleTrait {
> //implementacja interfejsu SimpleTrait
> }
>
> Innymi slowy prywatna skladowa "priv" w trait SimpleTrait jest po
> skompilowaniu upubliczniona przy pomocy pary publicznych metod:
>
> public void traits$SimpleTrait$$priv_$eq(int arg);
> public int traits$SimpleTrait$$priv();
>
>
> Ze tak powiem: adios.
>
No ale to przecież wynika z tego co napisałem o cechach. jest to
konsekwencją tego że dostęp do pola cechy realizowany jest przez
interfejs zmiksowanej cechy (a interfejsy muszą mieć publiczne metody) -
po prostu - to nie ma odpowiednika w javie.
To o czym mówiliśmy to prywatne pole klasy i jest ono jak najbardziej
prywatne w javowym sensie.
lopex
Marcin Mielżyński
Nie zrozumiałeś jak realizowane są cechy w scali.
lopex
Michal Kleczek
> No ale to przecież wynika z tego co napisałem o cechach. jest to
> konsekwencją tego że dostęp do pola cechy realizowany jest przez
> interfejs zmiksowanej cechy (a interfejsy muszą mieć publiczne metody) -
> po prostu - to nie ma odpowiednika w javie.
Ja rozumiem przyczyny. Ale to nie zmienia faktu, ze to problem.
> To o czym mówiliśmy to prywatne pole klasy i jest ono jak najbardziej
> prywatne w javowym sensie.
Ahh... rozumiem. Czyli jak chcemy miec bezpieczny software to nie mozemy
polegac na tym, ze z zalozenia prywatna skladowa cechy (trait) jest
rzeczywiscie prywatna.
Pytanie: z ktorych jeszcze elementow jezyka musimy rezygnowac?
Pytanie drugie: czy jak juz z nich zrezygnujemy to czy przypadkiem Scala sie
nie zdegeneruje do Javy?
--
Michal
Marcin Mielżyński
Kompilator scali będzie tą prywatność respektować, problem faktycznie
pojawi się gdy użyjesz tego kodu w javie. W javie natomiast, jeśli
chcesz zobaczyć klasę w innym pakiecie musisz ją upublicznić - pięknie.
Ja doskonale rozumiem Twój punkt widzenia - ale wolę mieć mocniejszy
język z lepszą kontrolą widoczności, niż pseudozabezpieczenia w runtime.
lopex
Michal Kleczek
>
> Kompilator scali będzie tą prywatność respektować, problem faktycznie
> pojawi się gdy użyjesz tego kodu w javie. W javie natomiast, jeśli
> chcesz zobaczyć klasę w innym pakiecie musisz ją upublicznić - pięknie.
> Ja doskonale rozumiem Twój punkt widzenia - ale wolę mieć mocniejszy
> język z lepszą kontrolą widoczności, niż pseudozabezpieczenia w runtime.
>
Dlaczego uwazasz, ze to "pseudozabezpieczenia"?
Wylacz verifier - wyjdzie na to samo - po prostu mozesz sobie dac spokoj z
dynamicznym ladowaniem kodu. Mozesz wtedy wyrzucic do smietnika rowniez np.
JAAS, security policy itd.
--
Michal
Marcin Mielżyński
>
> Wylacz verifier - wyjdzie na to samo - po prostu mozesz sobie dac spokoj z
> dynamicznym ladowaniem kodu. Mozesz wtedy wyrzucic do smietnika rowniez np.
> JAAS, security policy itd.
>
Nie widzę związku, w javie przecież musisz świadomie użyć private.
Przecież mówimy o konstrukcji której nie ma w javie a język ją pilnuje.
Jeśli chcesz semantyki javy w runtime, użyj pola w klasie. Nie jest to
dla mnie jakiś problem.
lopex
Michal Kleczek
Problem polega na tym, ze nie ma - a w kazdym razie ja nie znam -
dokumentacji mowiacej, jak konstrukcje jezyka mapuja sie na bajtkod. Po to,
zebym mogl pisac program swiadomie - czyli znajac konsekwencje uzycia takiej
a nie innej konstrukcji jezyka.
Jak na razie wiemy, ze "private" w trait mozna sobie wsadzic w d... Ta
wiedza nie jest nigdzie dostepna - wynika z postepowania typu "trial and
error". To ja dziekuje bardzo za taki jezyk.
Jakie jeszcze niespodzianki kryje Scala?
Mysle, ze z mojej strony to juz naprawde EOT.
--
Michal
Marcin Mielżyński
luzik
Mi to bardziej przypomina argument ludzi z C++ pare lat temu ? Java ?
toż to nigdy sie nie przyjmie i w ogóle jest krzywe! Słowo private nigdy
nie miało nic wspólnego z bezpieczeństwem (skąd ten pomysł ? hasła
chcesz tam trzymać ? - tego się nigdy nie robi w tym samym procesie) -
jest to tylko informacja że "nie powinno się używać" z zewnątrz.
Kompilator scali pilnuje tego private dla pola cechy i to wystarczy. To
że trudno pogodzić ubogą semantykę jvm z nowymi językami to żadna
niespodzianka - w takim razie wszystkie alternatywne języki pod jvm są
bezużyteczne - gratulacje - 3 lata mojej pracy też poszło w las w takim
razie, dziękuję. Miłego klepania w asemblerze-javie... (ba, w
asemblerze, bo dopiero wtedy wiesz co jest grane)
lopex
Ra
> piďż˝, 27 lis 2009 o 10:53 GMT, Marcin Jurczuk napisaďż˝(a):
>
>> On 27 Lis, 09:48, mario <mw.woj...@gmail.com> wrote:
>>>> Ostatnio widz� coraz wi�cej programist�w java wracaj�cych do skomplikowanych zapis�w i t�skni�cych
>>> new File("source.txt").eachLine{linia -> print linia}
>>>
>>> czy to jest wed�ug Ciebie jest to trudny i skomplikowany zapis ;) ?
>>> spr�buj napisa� to w jednej linijce w Javie...
>> W Scali:
>> import scala.io.Source.fromFile
>> fromFile("source.txt").getLines.foreach(println)
>> lub
>> fromFile("source.txt").getLines.foreach(println _)
>> lub
>> fromFile("source.txt").getLines.foreach(l => println(l))
>
> Jezeli tak bardz chcesz w groovym tez tak mozna:
>
> new File("source.txt").readLines().each{println it}
>
> ale nadal wydaje mi sie prostrze i czytelniejszcze, nie mowiac juz o
> wydajnosci przy duuuuuuzych plikach zastosowanie konstrukcji po prostu
> new File(...).eachLine{...}
o jakiej wydajno�ci m�wisz ? w pisaniu kodu czy wczytywania pliku ?
bo je�li to drugie to groovy przegrywa ju� na starcie. AFAIR wczytanie
pliku typu 10mb i jaka� tam obr�bka danych i zapis do pliku to by�o
kilka sekund vs 2 minuty
Michal Kleczek
> Słowo private nigdy
> nie miało nic wspólnego z bezpieczeństwem (skąd ten pomysł ?
Dobre - masz pojecie o Java security?
Gdyby w Javie "private" (a ogolniej - system typow, zasady widzialnosci) nie
mialo nic wspolnego z bezpieczenstwem, to cale Java Security mozna sobie
wyrzucic, bo nic nie staloby na przeszkodzie, zeby napisac kod modyfikujacy
prywatne skladowe klasy SecurityManager, Policy, ClassLoader lub zgola
String lub Object.
Idac dalej moznaby sobie wsadzic w d np. specyfikacje OSGI, applety, web
start i inne...
Naprawde - Java nie konczy sie na robieniu aplikacji webowych pod Tomcata.
> hasła
> chcesz tam trzymać ? - tego się nigdy nie robi w tym samym procesie) -
> jest to tylko informacja że "nie powinno się używać" z zewnątrz.
> Kompilator scali pilnuje tego private dla pola cechy i to wystarczy.
Nie wystarczy.
> To
> że trudno pogodzić ubogą semantykę jvm z nowymi językami to żadna
> niespodzianka -
Dlatego tez rozwoj nowych jezykow musi byc zsynchronizowany z rozwojem JVM -
bez tego te jezyki sa duzo mniej przydatne niz moglyby byc.
> w takim razie wszystkie alternatywne języki pod jvm są
> bezużyteczne - gratulacje - 3 lata mojej pracy też poszło w las w takim
> razie, dziękuję.
Nie trafiles, to sie zdarza. Przykro mi... naprawde :)
MSPANC
--
Michal
Marcin Mielżyński
> Marcin Mielżyński wrote:
>
>> Słowo private nigdy
>> nie miało nic wspólnego z bezpieczeństwem (skąd ten pomysł ?
>
> Dobre - masz pojecie o Java security?
> Gdyby w Javie "private" (a ogolniej - system typow, zasady widzialnosci) nie
> mialo nic wspolnego z bezpieczenstwem, to cale Java Security mozna sobie
> wyrzucic, bo nic nie staloby na przeszkodzie, zeby napisac kod modyfikujacy
> prywatne skladowe klasy SecurityManager, Policy, ClassLoader lub zgola
> String lub Object.
>
kawałków dotyczących bezpieczeństwa w scali czy czymkolwiek innym.
Poleganie na private w aplikacjach domenowych jest co najmniej dziwne.
> Idac dalej moznaby sobie wsadzic w d np. specyfikacje OSGI, applety, web
> start i inne...
>
> Naprawde - Java nie konczy sie na robieniu aplikacji webowych pod Tomcata.
>
Kto tu mówi o aplikacjach webowych ?
>
>> To
>> że trudno pogodzić ubogą semantykę jvm z nowymi językami to żadna
>> niespodzianka -
>
> Dlatego tez rozwoj nowych jezykow musi byc zsynchronizowany z rozwojem JVM -
> bez tego te jezyki sa duzo mniej przydatne niz moglyby byc.
>
Przy takim podejściu nic by nie powstało.
>> w takim razie wszystkie alternatywne języki pod jvm są
>> bezużyteczne - gratulacje - 3 lata mojej pracy też poszło w las w takim
>> razie, dziękuję.
>
> Nie trafiles, to sie zdarza. Przykro mi... naprawde :)
> MSPANC
>
A jednak efekty mojej pracy są używane na całym świecie niezależnie od
twojej opinii.
lopex
pietia
.
>
> Nie trafiles, to sie zdarza. Przykro mi... naprawde :)
> MSPANC
>
Z czym nie trafil ?
Michal Kleczek
Z trzema latami pracy.
--
Michal