V navaznosti na diskuzi "prochazet pole odzadu ci odpredu" si dovoluji
nabidnout skript pro refaktorovaci framework RefactoringNG, pomoci nehoz
muzete snadno zmenit
for (int i = p.length - 1; i >= 0; i--) { ... }
na
for (int i = 0; i < p.length; i++) { ... }
Je to trosku delsi, nicmene verim, ze pri minimalni znalosti vnitrni formy
stale citelne:
// RNG script
// for (int i = p.length - 1; i >= 0; i--) { }
// ->
// for (int i = 0; i < p.length; i++) { }
ForLoop {
List<Statement> {
Variable [id: i] {
Modifiers [id: m],
PrimitiveType [primitiveTypeKind: INT],
Binary [kind: MINUS] {
MemberSelect [identifier: "length"] {
Identifier [id: p]
},
Literal [kind: INT_LITERAL, value: 1]
}
}
},
Binary [kind: GREATER_THAN_EQUAL] {
Identifier [id: i2],
Literal [kind: INT_LITERAL, value: 0]
},
List<ExpressionStatement> {
ExpressionStatement {
Unary [kind: POSTFIX_DECREMENT | PREFIX_DECREMENT] {
Identifier [id: i3]
}
}
},
Statement [id: body]
} ->
ForLoop {
List<Statement> {
Variable [name: i#name] {
Modifiers [ref: m],
PrimitiveType [primitiveTypeKind: INT],
Literal [kind: INT_LITERAL, value: 0]
}
},
Binary [kind: LESS_THAN] {
Identifier [name: i2#name],
MemberSelect [identifier: "length"] {
Identifier [ref: p]
}
},
List<ExpressionStatement> {
ExpressionStatement {
Unary [kind: POSTFIX_INCREMENT] {
Identifier [name: i3#name]
}
}
},
Statement [ref: body]
}
Z.T.
--
Zdenek Tronicek
FIT CTU in Prague
Oto Buchta napsal(a):
> JSR166 je podle mne také jeden z důvodů, proč se aplikace
> distribuovaně nepíší. Použil někdy někdo z Vás balík
> java.util.concurrent? A pokud ano, používáte to běžně?
> ConcurrentHashMap je dobrá a často ji používám, uznávám, ale jinak?
> Proč je vytvořen opravdu silný a IMHO složitý a těžko čitelný
> mechanismus pro paralelizaci a konkurentní přístup místo jednoduché
> konstrukce zavedené přímo do syntaxe jazyka?
> Proč se nikdo neinspiroval třeba takovými jazyky, jako jsou Oz, Alice či
> E?
>
> Jak by se krásně programovalo a paralelizovalo pri konstrukci jako
>
> int result1,result2,result3;
> concurrent {
> thread 1: result1 = method1();
> thread 2: result2 = method2();
> thread 3: result3 = method1()*method2();
> }
> if (result1==result2) {
> ...
> }
>
> , proč k tomu používat šílené Future? Nebo by to šlo krásně vyřešit
> pomocí anotace - jak by bylo jednoduché a elegantní přidat anotaci
> @Future k metodě? A nebo zavést Ečkové eventuální volání metody
> myObject<-futureMethod()
>
> a nebo rovnou Ečkový slib
>
> int futureResult <- myObject.futureMethod()
> when (futureResult) {
> if (futureResult == 4) {
> ...
> }
> }
>
> Věřím tomu, že většina programátorů by tyto jednoduché konstrukce
> velice ráda a často využívala. A paralelizovaný kód by byl daleko
> čitelnější. Jednu dobu jsem uvažoval, že bych si zkusil napsat něco,
> co by to nějak inteligentně schovalo. Ale nakonec jsem to zavrhl...
> Třeba to v Javě 1.10 bude...
>
> PS: Od dob foreach používám reverzní procházení pole jenom v J2ME a
> všichni, kteří kdy takovýto kód četli,
> velice rychle zjistili, že je to moje úchylka :-P
>
> --
> Oto 'tapik' Buchta, [email protected], http://tapikuv.blogspot.com
>
