[ir4pp1:2008] - Domaci - komentari #2 by "Vanja Petreski" <vpetreski@gmail.com>

Evo ja opet da popricam sam sa sobom i da postavim jos pitanja za koja se
nadam da ce ovog puta biti odgovora.

U suprotnom (ako odgovora ne bude u dogledno vreme), moracu da uvedem
razumne pretpostavke i resim stvari na nacin kako ja mislim da treba, a ne
kako je sugerisano postavkom, a sa pretpostavkom da cu dobiti vise poena, a
ne manje ;)

Pa da krenemo:

1) U postavci se kaze da ime klase koja predstavlja parser ne treba menjati
vec da treba da ostane "parser". Po Java Code Conventions (
http://java.sun.com/docs/codeconv/) klase se pisu velikim pocetnim slovom,
tako da je ovaj zahtev nije u redu. To sto CUP/Jlex programeri imaju ovu
praksu, to ne znaci da je to OK.

2) Ocekuje se da se parser pokrece sa "java ime_paketa.parser
imeMJfajla.mj". Ukoliko student donese gotov proizvod, onda se nadam da je
ok pokrenuti ga sa java -jar compiler.jar input.mj. Takodje, nadam se da
sugerisano ime paketa nije bitno..

3) ResultCollector ima smisla, ali tu ima jedan problem.
UnsupportedOperationException koji je sugerisan u ponudjenom interfejsu je
RuntimeException koji predstavlja superklasu exceptiona koji se bacaju tokom
normalnog rada JVM-a i metode nisu obavezne da deklarisu throws klauzulu
bilo koje podklase ovog izuzetka ako je ispaljuju. Dakle, na ovaj nacin,
klijent ResultCollectora nece biti prinudjen da se obradi izuzetak, tako da
ovo nema smisla. Predlazem da se throws ukloni iz interfejsa.

4) IMain interfejs apsolutno nema smisla i ne vidim nijedan razlog za
njegovo postojanje osim mozda da zbuni studente. Naime u postavci se prvo
sugerise da se parser pokrece kroz parser klasu. To znaci da ta klasa treba
da ima main metodu koja pokrece ceo parser i radi posao. To je ok. Medjutim,
odma posle se pominje IMain interfejs koji ima vise problema:

a) sam potpis metode je problematican jer je zbog toga nemoguce definisati
pravu main metodu. Ponudjena main metode nema veze sa necim sto startuje,
tako da je neprikladno nazvana i samo zbunjuje. Takodje, nije jasno zasto je
argument niz stringova, ne samo String ili File. Ali ovo i nije toliko
bitno, ako se izuzme zbunjivanje.

b) U dokumentacionim komentarima stoji da i) ova metoda pokrece parser, ii)
da se moze vise puta pozivati tokom obrade. Ova dva zahteva su potpuno
kontradiktorna iz prostog razloga sto bi se na taj nacin parser kreirao i
pokretao vise puta!!?? Zatvorili bismo krug u dobili stack overflow..

c) Nigde nije receno kako se koristi i ko koristi ovu klasu - upotreba fali.

d) Reset? Cemu to?

Dakle, ono kako ovo treba uraditi je nesto ovog tipa:

ResultCollector implementacija pored metoda iz interfejsa ima i logiku za
brojanje i realizovana je ili kao singleton ili se klijenti ove klase brinu
o tome da je jedinstvena instanca. Klijenti (lexer, parser) u odrejenim
trenucima porepoznavanja onoga sto je navedeno, koriste ovu klasu koja,
dakle, cuva tekuce stanje obrade. Naravno, moguce je pozvati metode za
dohvatanje odrdjenih polja koja se traze u toku izvrsavanja. Po zavrsetku
obrade parser uzima sve rezultate iz kolektora iz radi neki dump, moze biti
na izlaz moze biti u fajl, moze poslati te podatke na Mars. I to je to.
Znaci predlazem izbacivanje IMain-a iz domaceg, jer uopste ne vidim njegovu
svrhu i ne vidim kako to moze da radi.


5) Pri deo domaceg tacka 2 (16 poena), stavka pod 04. Zar ne mislite da je
ovo previse komplikovano i nepotrebno. Na primer: "brojanje metode koje
imaju 3 lokalne proenljive, pri cemu su imena u leksikografskom poretku".
Mislim, o cemu mi pricamo? Mozemo mi da racunamo da li se u trenutku
prepoznavanja temparatura procesira popela iznad normale, pa ako jeste, da
onda racunamo, ali da li ce to doprineti da mi bolje naucimo da pravimo
kompajler? Tesko.. Narocito sto ima mnogo tacaka ovog tipa, a svaka nosi po
1 poen. Ovaj deo treba potpuno revidirati u uprostiti...

Pozdrav,
Vanja