[Modelinterpreter] operacio parameterek multiplicitassal

[Boldizsár Németh]

És már le is van implementálva.
A biztonság kedvéért még megnézhetnéd hasonlóan beállított HashSet és 
HashMultiset konténerekkel is.

Boldi

On 2015.06.18. 8:54, Dévai Gergely wrote:
> Jo hirem van: Boldi javaslata alapjan megcsinaltam a merest ugy is, 
> hogy az ArrayList kapacitasa a konstruktorhivaskor 1-re van allitva. 
> Igy nincs kulonbseg sebessegben a referencia es a max egy elemu 
> ArrayList hasznalata kozott.
> A javaslatom igy mar egyertelmuen az, hogy nem kell semmit kulon 
> wrappelni, hanem az osszes parameter egy ArrayList-ben megy be, aminek 
> a kapacitasa a multiplicitas felso korlatja alapjan kerul beallitasra.
>
> Gergo
>
> On Tuesday, June 16, 2015 19:09 CEST, Dévai Gergely 
> <deva at caesar.elte.hu> wrote:
> Sziasztok!
>
> Egy gyors meres alapjan egy elem atadasa, az uresseg vizsgalata es az 
> elem lekerdezese ArrayList hasznalata eseten kb. 2-szer lassabb a sima 
> referencianal.
>
> Udv,
> Gergo
>
> On Tuesday, June 16, 2015 18:15 CEST, Dévai Gergely 
> <deva at caesar.elte.hu> wrote:
> Sziasztok!
>
> A mult heti meetingen felmerult az a kerdes, hogy az operaciok mit 
> csinalhatnak a paremeterkent kapott objektumhalmazzal.
> Pl.: Egy [0..1] multiplicitasu in-out parametert kinullazhatnak-e? 
> Vagy - forditva - egy null parameter helyebe adhatnak-e vissza egy 
> objektumot? Altalaban: valtoztathatjak-e szabadon a szamossagot (a 
> statikusan megadott korlatok kozott)?
>
> A valasz az UML szabvany szerint igen.
> http://www.omg.org/spec/UML/2.5/Beta2/PDF
> 108. oldal, "Parameters"
>
> A parameterekhez UML-ben lehet "effect" property-t rendelni, ami egy 
> tervezoi dontest fejez ki azzal kapcsolatban, hogy az adott behavior 
> mit csinalhat az adott parameterrel: create, read, update, delete.
> A szabalyok viszont furcsak:
> - "Only in and inout Parameters may have a delete effect.": Azaz egy 
> in parameterkent kapott objetum is torolheto!!!
> - "Only out, inout, and return Parameters may have a create effect." 
> (Ez logikus.)
> Az adott parameterben kapott objektumhalmaz szamossaga tehat (a fenti 
> szabalyok es a multiplicitas betartasa mellett) letrehozas es torles 
> hatasara valtozhat.
> Arra sajnos meg nem talaltam valaszt, hogy egy behavior kiszedhet-e 
> egy objektumot a halmazbol anelkul, hogy torlne azt, vagy beletehet-e 
> a halmazba mar korabban letezo objektumokat...
>
> Mindenesetre ezek alapjan az implementacionkban [0..1] multiplicitas 
> eseten sem johet szoba a sima objektumreferencia atadasa out es inout 
> parameterek eseten (sem), mert elkepzelheto, hogy null megy be es nem 
> null jon ki. Egyre inkabb hajlok arra, hogy minden parameteratadas egy 
> (lehetoleg kis koltsegu) kollekcio segitsegevel valosuljon meg. Ez 
> esetben nem kell wrapper osztalyokat csinalni a boolean, double, 
> BigInt es String-hez.
> De ha van valami konzisztens modon implementalhato optimalizacio, 
> szoljatok!
>
> Udv,
> Gergo
>
>
>
>
>
>
>
>
> _______________________________________________
> Modelinterpreter mailing list
> Modelinterpreter at plc.inf.elte.hu
> https://plc.inf.elte.hu/mailman/listinfo/modelinterpreter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://plc.inf.elte.hu/pipermail/modelinterpreter/attachments/20150618/be3edf1f/attachment-0001.html>