[Java lista] Pattern.compile bug (jdk 1.5) -- meglepo vegkifejlet

[Marai Laszlo]

On Wed, 5 Mar 2008 14:28:46 +0100
"Gabor Szokoli" <szocske at gmail.com> wrote:

  Hali!

Mivel megvan a megoldas, ezert ez mar csak csacsogas, ugyhogy akit az
ilyesmi nem erdekel, ne is olvassa tovabb :).

> Ha a feldolgozando bemenetnek hierarchikus strukturaja van, akkor
> sokkal olvashatobb lesz a programod, ha ezt a hierarchiat koveted az
> elemzeskor.

Nem ertem, hogy ez mibol kovetkezik. Ez akkor igaz, ha proceduralisan
szeretnem leirni az elemzest, de en pont azt akartam elkerulni, mert az
szerintem onmagaban kevesbe olvashato, mint egy deklarativ leiras.

> A felsobb hierarchia nalad az, hogy "vesszovel elvalasztott
> mezok".Gondolom a mezokben escape-elve fordulhat elo vesszo. Ez

Nem, nincs escape-elve. Van string tipus, abban idezojelek kozt lehet
barmi, igy vesszo is (persze idezojel csak escape-elve). De akar az is
lehetne (elvileg) holnaptol kovetelmeny, hogy az ido tipusban a
masodpercek utan adjuk meg a szazadmasodperceket is, vesszovel
elvalasztva. Persze nem lesz ilyen, csak az elv miatt irom. Ebbol eleg
jol latszik, hogy altalanos esetben (ha bonyolultabb elemzes kell) ez az
elv nem mukodik jol. De mar maga a string tipus definicioja is
elegge megnehezitene az altalad javasolt megoldast.

> alapjan meg mindig olcsobb szeletelni es egyesevel elbanni a mezokkel,
> mint egy orias-regexpet epiteni az egesz szalamirudra.

Az oriasi regexpet a program epiti egy igen egyszeru kis ciklusban, ami
semmivel sem bonyolultabb, mint az a ciklus, ami az elore darabjaira
robbantott stringen menne vegig. Raadasul pont ebben az esetben, ha
egyszerubben szet tudnam szedni az inputot elemeire, akkor nem is igazan
kene a tovabbiakban regex, mert a konverziot elvegzik a standard java
tipusok (Long, Integer, stb. es SimpleDateFormat).

Szerintem elvi es olvashatosagi szempontbol teljesen rendben van, hogy
keszitek egy leirast (arcoskodva akar nyelvtannak is hivhatnank asszem),
es abbol gyartok egy parsert, ami egyben megesz egy egesz sort, es nem
vacakolok kezzel azzal, hogy valami trukkos algoritmussal szetbontsam
elemeire az inputomat ugy, hogy ebben a trukkos algoritmusban valahol implicit
kodolva van az egyes tipusok leirasa (lasd hol lehet vesszo), ami
raadasul borulhatna is azzal, ha modositok valamelyik tipus leirasan vagy
ujat veszek fel.

Amugy a szalami gyarto kod kb. igy nez ki, szerintem vallalhato: :)

private String createParserPattern( Metadata meta[] ) {
        String patterns[] = new String[meta.length];
        
        for( int i = 0; i < patterns.length; i++ ) {
            patterns[i] = meta[i].getParserPattern();
        }
    
        return Util.join( patterns, Protocol.COLUMN_SEP );
}

(A Util.join a String.split metodus ellentettje, az adott tomb elemeit
osszefuzi egy stringbe, es az elemek kozt a megadott elvalaszto string
lesz.)

> ? -> return new Ques(prev, GREEDY);
> {0,1} -> new Curly(prev, 0, 1, GREEDY)
> 
> ami nem ugyanaz. Persze jelentheti ugyanazt, de ez ennyibol nem derul
> ki. A * es a + bezzeg Curly-vel van implementalva, azokat tenyleg kar
> lett volna lecserelni :-)

Hat valoszinuleg az volt, hogy optimalizalni akartak, ezert a gyakran
hasznalt ?-re adtak egy 'gyorsabb' :) megoldast. 1.6-ban ez a switch
ugyanigy nez ki, meg a Ques implementacioja is. Viszont ha tul kicsi a
stack, akkor az exception trace-eken latszik nemi kulonbseg, de nekem
nincs nagyon kedvem tovabb vadaszni a kulonbseget. Orulok neki, hogy
mukodik.

  atleta