From 7aa2ee9e67c82f0b8e01dad2543c9b539d58dedc Mon Sep 17 00:00:00 2001 From: halw Date: Thu, 14 May 2009 00:20:57 +0000 Subject: [PATCH] Author:halw Date:2009-05-14T00:20:57.000000Z git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@215 abb3cda0-5349-4a8f-a601-0c33ac3a8c38 --- .../current/method/_images/VoidSafeVEVI1.png | Bin 0 -> 6494 bytes .../method/_images/VoidSafeVEVI1.png.data | 3 + .../current/method/_images/VoidSafeVJAR1.png | Bin 0 -> 12896 bytes .../method/_images/VoidSafeVJAR1.png.data | 3 + .../index.wiki | 242 ++++++++++++++++ .../creating-new-void-safe-project.wiki | 73 +++++ .../void-safe-programming-eiffel/index.wiki | 41 --- ...afety-background-definition-and-tools.wiki | 268 ++++++++++++++++++ 8 files changed, 589 insertions(+), 41 deletions(-) create mode 100644 documentation/current/method/_images/VoidSafeVEVI1.png create mode 100644 documentation/current/method/_images/VoidSafeVEVI1.png.data create mode 100644 documentation/current/method/_images/VoidSafeVJAR1.png create mode 100644 documentation/current/method/_images/VoidSafeVJAR1.png.data create mode 100644 documentation/current/method/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki create mode 100644 documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki create mode 100644 documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki diff --git a/documentation/current/method/_images/VoidSafeVEVI1.png b/documentation/current/method/_images/VoidSafeVEVI1.png new file mode 100644 index 0000000000000000000000000000000000000000..9ebc80e452566e1c3f60fbf96a3bedd14329ec7c GIT binary patch literal 6494 zcmb_hcTiJXw?BXsK?DnmbmSr^3etN(M2b=b5m1ocdkKUdP>~`8QHpc~MG**>7D^!D zDiW%pDJq00CG>_z~K4;BZ>$lHIyKQ02%PqtW z006J4iJ>(Bu#lN!0v9Xud|mu0hIu&}VsbAW0FL+kK3H<)jtetEPOz!@4bJcEyr)l} zUQ=lc`Ww1o555)w_6ZIHs^LQ>Oz0Sx2^o5ZyNCIPfPI65fKx{$rIe#3UIVL`q@-axl7A%%%?{%d|jn7b!HW;|N`Z?o&cfq|YuU|@GB z56#3lew*3&f&)B(cf>In01&)rYIw~is(2k2o8kDy6|)&m8qz`vsy_|ggeTpG1kRl{ z4EVvdl_Kra5?H4uZ#~~3m~Cj}Yhb#bqfss>bfib;zP`q*2y6CB2GSl9sm3+8eRv*U zklg>MbINs%oo>?Te?%jY*C1hSCku%x)~$~vx)WwJ4`@D~IL&Zk`{GOiZM{HQ88bSF z)sq8&cw$CYNo9^<%MKfGyROnWi(9fnHoc<2B}=Qsq5<()k8vnd7S~8QUp2*fMIo2Rq4lqBEQA#f}fDO-uBiu_JUs6*ZhDH`%;8u8yiIFw#J>NK%9*J7?%uZYacYS6MXR7H>E*8eou{D$nXX$iH-aQ_*@~b<)VTP* zyk++4tIPNtIk{JBaF>8Txom4QSh!cCMizT=#cuO5lt3tQ&cZGFzPJLmxt3ieDwe{H106iE`C-D3dJodQA&!7 z<4Dhc&;7RP7J%P+9pd)gNwViUw9$~uS`65#Ufa%|n{z-og>I(fLD3!K1w=52I-0fi zBjS_lWMEVRrD(3KbF*rS6ix!kO;2V@>$#)1G47bB4RgsFd0PNrxw03(__+k}KHn*( zdL6#GdBra1U})K0MtnV0<77kXoC(*7l8D~16cV1gg~hk65R4hyDXoXg;+Lnkl6iJ; zGBPsWnbVf%irVMSo^n6P%R0Kb*Ef^)$c;49HJGo^O8(XJNe(~5NOuaGoy`q%wRWqi z&XGBD#cBWRT3A<)cm0RDeG&OP(wRH-RCf7@nDMq?YkR_pfZ7|{cBqJDxqdVvc34{; zM6094<`mt0Qc$%26Y{;X`YFwZINa{e&GiFGy z{?uR2W)7*yg>*g#js@MDVdHtPFe^6V#DRvL@lCyJ(v`V^?LDD|L?iCf_xu&l_Y3fX zn!X1S5U0asf65x|1`_AjdVf91w&si9r%*Xqg?*3J&NR;fg0x4$5NX18*H?RcoN2#) zwD=nv8_TFWl7~n^_UHs!p{jpRhoYpHm#;|9tB$~{rT4-|*EUi7=hOJw4XBSDnxj0o zq)2j%n#pXQT()!mUTV_$ax}ABIr0~~RCn>Ak%&q`K94CxiIrC?F2~{rJvYm9?Jf4r z%ZTX`xfjrJ@pebN?e6gOtsuQQZj;Q{SoqQ{K4#j~M(u^ZWOt!lbC#50>Zdn_R$uk~-y9 z!f&9nJ*4dawf2O8nS}*`+GD1b0zcMImT9i5GN*QCm#GZ2fv!wIz>}u!oT9#W5OEi~ zU;4MN#5%FKTMJ`lNj|#Y6}J_x%_x82%ejYn+3x!%Au~3<-tm+|KdS%9BCI!!XYTQn zz~1lMvc5dg5bVLcP2adeK{)=VsXT&B;C3T>IBJnPHvaI%nf11HX00Gxfi`R-6h57& zu8{HjKPJUbKH3hNMi8F_gEoIY$nVDg6^15s=(UV3c8*nv5)P3u)Kl4JFem#s)cof4m zD&saiJ_6#cO75LJ@@YO0V}%dRcaJoIKWhzMwlSsNajBX?PdC|hbUuPiITa|A8k@tk zo>8>kd7eSNKMhwTk5R(L%eG2J@fETm0`77rmD; zldxKO-VeHvZt2t#QOWPdTq&B26R)@babo?BI+RMuxKbRuNc2|Fbl_6F@Yue=pjP-6 z$C|stc8edD^^<8RTCe>^rp55JCzyJ;qJy0w#f&F&twsf-_erHl9J-t)HPi^C>$>(>SvoOiz&kC44F`{n60;H!hUY-V6H!90e?_hWyhMuq|JqxzQKyw26yT8F48wBVo zP;S)+0k}@>9|v5|<5?uk9_+_?$hUuezh=!D$0u~dpt>Mu2$WoK(qXu?Od_$pnjUvH z!Xt*vs=*Gp`pzDjDOF4|%+*fDn7?6fFRbio$e*dzvVk1yrTMe!LsZ-jZ8_Q@A~k_h$+y?QV%bSB~PmU1pSlC+|a~qUELSRE^V6l4c~9z2ZmH zZ1^sq+ISfIQ328vDp^M#odR7EbT$)ocKYTN*;aJ2$+<<)LAliCzRwzZZY{uA zQLGOUs9iY}#P;rnR4*w^X zrhz(AMyvYDs^{^sM&|;~z+ViQt#`7`i^+aJMaw7*_X9l4i=p+;-1DTuohd5KmXCa2 zZK_^VjGhXefK2B`<1)N^^u>H~{v9OEJJT<41y?j!C+&^pch<5j|0Cyx$sgEX{yS{2 zB7{i8dIegp#!{m%Vp=tjlf0Z;7Y2_PMdqNN5U=M1@ayLv0qH$*6NIp_NZ=1lXNIm6 zk3QDs2mUi|?=|tce6Lp3w-ZkE+dgkiesbHEWp&p|Y4B-0wkH45vVOm}O|V$YjQeIA zYP@_iwu4}b6D+0^Z{82tUw*UL;@GsMS=`C%WlJ=M9Zb_lqTJ6r zv#7~!M`rlf9FkT^8iq5U57s<82RBbEl~yg5=}(2~Ld`ERcyG8e-9iV-D=DHI`_lc| z?=J5?T}0<&ZwyAbD)W_4xaX}K&AWneORo=>bbSytd@NK08mV50a}8uU@cu(rh&HU; zOl>F0jL?uC(W_C~Vy-mrS7)ChYS-PwS4tLzcseC@#&4thO4Cd7y_IwPIQ3IBa3zL_%)RN@&Mse#)xuW$%GKXkHM#@IOc%B4EH?+9cTeN+IF+$|-RTI^| zL=G=$v&3iccF063Wm*5U+Fr9ScyTF2I=)mh+P}hED4T@H&l`9U<4RSDP+3yW^^GkF zIuIDvu_c__7wP+2zF7Nkoj-o+}#HGwQCW+dowtc zwH^2FC3UEr$0rStU1kcZ0}FJ#78_NL?88b24vL&LF2?XH(sJE!#6akSOw9^9#f}BQ z>Hnk3tW3r!9Oh<<#hF(=uYUpPo6-tN$>gmE2_P$=+=zFWvLxtkO0D0z8{nz1;Phr> zo4*&jP^AP>i8RyG0&Hs1%Ai?Z3g9oH@SpF4zi|uDQ$kwjW=6j%mgTXOXIvm4JD(*N zKPu2(i8!nrj~eM*e>MRWR;KOC!`R>GAg&KdC+qY}UzL)W%XRZxTk2bk?1~GT}Oz(Y7xBVJ&z2a@v$qEXN ze_3$?H<_-E0p&XXnV5gKoBx-p>okAuxKvc^S$U4cZe~$iP$5}2K6SrX?eRve8u6?})n_X2Rsi&pk}yl+hZQVD zdL%c*u9pmw#vSk|BHan-Q_{lOj3NF_VBnn|UUVn4%hHtZ19P)oKe}Jq)7tRIaA;Rg zpPIbd=Xg2kb{h@An~SeJ!)Otyq-LqMV=9RCJ-1-~+5NyPf8JAvAK0;{m1Ws*EN5R7 z9XHTicoEpu(~MjKd(m>TT;61RXp@q5jB?QOxnP0r>50@$q{#3oAj;(~rG)1mX-; z1$!9j4-TAYuae3d)}929A#+YfpEYI&-aU}o!kzdFG{`C}+^p(3Etk2c(y~xwzztT^ zp3W2i%8xR$EQatSk6nJG91H99vE?8u*A0IT^_pi9|N42#7n{33j)$RM3C#LHZ!Phl0a{{!igzp2hY-of7;f1*6D zH9oh0uj@59t)X*R&3UUJX6kH}i1TY}3zhcjviSR@^e8pi{3Ya|bgx=Xyu{9nh#gGZ zQ){=?_Bnm3z*k{KkgR_21Y@7_82jF}@n`;N`Q3i1>`D6B3v~tl3S9|d$`>0{7Z`n1 zh`wfCf)-sy)^4PA;UvblLzpF|{@NVmo|aBNW|@li^_+8Y{;qo^v{T6h^LaVT5gsge z;6;>fEemCTZ8S!0da_&f%H^aH?0Jxfxz{6D3U)8`^d7@$;7?kK?01tN5ZX1Cn97TD zkmSZhWMgl=0}hP;*#my3GCR`*?s;z|$+=Qg zD`{2BiNJQr5-qrhT1dr1g78U8m@MGcPGaotRpBT&sDtTn+t_>Vg(RAW>BAr~_Z!@bj}#;a?io$EyOb zxRI-VbqJt+iD~h@9}&o|=?w|3pdYJ6Sxd^AbMpP2AjAO7D6Wvb<1IaobhcppGP_=b zla=jV9+CWjlXZ9~qBwgpuABk_h zc@@Z+=)q!h_TN7Z?0@eU!vWAL>6^&U4JH8uRx}mQaYo|ERdva62E0YF;_)+nh%ruL>ipQaRN{dus{F%MG^jOP>V%^1e zp(t-S-{oL$g$;k_3n&jgmU8sYDzj2|XZ~Y-|5pzDpSkt7CxRQw*vbZS7ARk34%xaL zN0_X*$3u9A1@h#_Mu){^u!GdCztHvsF z_~g97(%AjCh(nnp0IMw&HC1IBX8!u>Dl3pq-F^TgeAp(@uUw7dylOmAMrw5XMO5}L z`|6s&(JeAs8>e8F7P0TuQ5Ov8ckdnkFQh+RtK{>}&dzA1F&@gGF~2vPng5n`JQ_`e zu>fKAol%>8f6Gys;;R}O-~3v8bpd3BQ&K!!1wR^0KdF zPqvgXOiVXszAyV@3g0B|E}(y$jg4(R68XiiWhzk8Py{1hi+E`mrzBbyzy?rnh+slR vWVRLi56xa*{`BdG12BSqo>t&-z+kz6kc&4Ioo#3SMgUB2SQx?$Tps=xOPAyt literal 0 HcmV?d00001 diff --git a/documentation/current/method/_images/VoidSafeVEVI1.png.data b/documentation/current/method/_images/VoidSafeVEVI1.png.data new file mode 100644 index 00000000..cfa1e2c5 --- /dev/null +++ b/documentation/current/method/_images/VoidSafeVEVI1.png.data @@ -0,0 +1,3 @@ +title=VoidSafeVEVI1 +author=halw +path=content/voidsafevevi1 diff --git a/documentation/current/method/_images/VoidSafeVJAR1.png b/documentation/current/method/_images/VoidSafeVJAR1.png new file mode 100644 index 0000000000000000000000000000000000000000..b757a42b9e07f6177a505e25c163fdff0514cca9 GIT binary patch literal 12896 zcmZ8|1yEc~uUpAbl~i zH?%Xgftp%dfpAbMsQ^0K3tiOO#>LLm1Of$>Vh-~HRPcXPJ0txURtl)8r4fkZ8WRg(zbbiVMqUOa8r9j3w?mq4piS!6A6$}UdU?tc2=fVCZG=D?I3`L z{6GC2>`Tg+?61mQg`v&xs(B3&`zX1D0J!_0oYxwzkA4GhM)Seq;iPF#LrIfh}@=o%z zkEi(=Iy)7E#pUVcWUcbFxB?m)EV{-_Ky&p@WA{R*t-Aa- zyLom}SpJ>)U)q;Fj*##E1yP_hzH95pemm3MOQ8F3vk}Si*yu}f@hUG)NJQ%XzR|=p zojn|x+_i>f2hDe!%HSTW$p*!jf;JByAHQ_%M$}&v3n9(J?Rt9O;ZCWR4j1i)s=cd| z#{BwlDK=iVy=V@_*Cy5G=0yLYst`9%u}Zz?89hM6GXOqO=f_OCw)j9>VIT!XMcWfzm(EjX1gG1aln2c()V2kizg~~jtJQnL^55#`IllAj_qy`>C!eRBr$|UltR#(r zfe{`a&cw+0MS~S%x1-aJTdQl~%U5Hl|>JemDh+ z$h&OLx!%kOB(VX9$nI2x06Cw`T~t9!Q}Lg*r4H&Mj3`~Feg=Ayo&nuc28KJVT3*RQ zHQePW$#%WB%qT+$M({{Rh3`;AbiYaCg^FphY0}3-{@k9@l1v(5Az-r0^>69)8dNPJ z)pq~hOucF>$kYW6Hi~j;YU+Zx7M>u|pa4Fj8j8{nh(juGm1i0QipaJWbVBULkC#-7 z`^XJfmCdJ%h`^v^iOOJ-9Hqx8<7Y?Jv;FvmWgRmZiQ29-p^FBfcCfR zj`ui9b=%i^VrQRD+L-7@F(iu2xC+pHJM`^yLLo!qSq11Fu!wKaY zxrmP-yl?x3)Ab$6{;Y2GX&}SsgI|4Jb|IeFvHK1mne%F3QPR+rpaA0M zqxmduzWXB&IF=<9jy$EuEB5&AqZu-Y{~}uH0T}Kd(j+*Us>Y_P*!`f3e3?sA{YqV00f%l7WCX4$V- zv^BcL1|@UxF+^YgNNWR2VOp@<||nPv~0<;|l4*NYCA7VzHWIw$k7 zECRQFYC6Gb5zh|uNhbVhPq&|tWxg>;M3y#mC6rFyFG{^xt|s~6vmux z{u_*)wMuCu0C8GA4fCzIn8C%-7aL@$GvbCI=AnK2wwEy0Qh7)mDd76-bwzkL_rAsQ zEJlVI&f71+(sM0wPOnZ&_nzrY-taggvsNJQU!ER5a8Xxhk7_zvq3tBAAX3?AA$yXcikbZ#- z1XbWRI;H#UNralLhyJd34h{x${HdjcZ!bE=3EmCLvh1RQ>^^LYzME|%#XRh%+ z7)MUs_BqlM-}-2j1+JsXVPEiPan)(e{0>3J$NPXBx9op&LX29~KTlslHi*I^pZR6> zZnmb^-53*tO4|bFpm`!|ns~FXT&iv?&#>C-lTV>f-$`Nb3YgiaShE_KGJ#pQ&(#PP_E2daqCB$2>2S&7U8y9akB^e zid3B(wCNr%JZ|b9JT3k*7krp1(5cZ>SN0DwSDUy7qFVFJ12+K5tbV zKf`uBAOETy-Brl99FwfXM$b=Sc63(@wX9Z$dSG}v?88V~j@o70_PZ$??RI*}{?UK) zs_>CO4%YyW9!w8C8&Z#shS$zW*qX(#7e_rA+o=N9H6pXOoQSoiUO)mL5xv>Kc7 z@E+9BCj$aGKK)o~ayU6*OeN!$TWe)yfGJoxS5b$&2G0+Ulgo!__DkKSpWJZa(>>{IGn73YBO016@YS-?AOv z5^s91*u(W{hq}~vbmN90zCh9^9>fv?=z5|uo0$%^)F45XQ+}7)vs-!H*PxZBBl#U2 zA^s}65mSP)haE4gCC{Clk6Oz$YmsfX$FawP)mnsthhu^cfIciM|SOkK#{GltAp0|&PUNt`-S%GNjXwVIP9D$jt*7LVNFi-idMCT72h4IJEk5_IHI1#UopZ0d3b@ra z@`vNur_%wfI6)izERbQn$9cty)2O=3KmieoBd-m=uOa@AtCRKiwEM^*+ryaE3=142 z-y`Prn#;}*&ffWMSt~X7JzcmCQ6ZPR`gS_uyo)ybzU;}rLiQSAW}psWNlwdC6D(f0 zLjr2)&vQehK`)yQe@`UB`-Slr+>+Lp!=k};v{6oOp(b4Nw5OX7JKgJ{?r7yM7!0)J z0_QSV2>6<{s*2_DeF-{zgijGJW^vInRxDLw+F1pm!=PJoC$fREhW z-A9r+aQ*>obpYbmv zwQbvPpwAhp8}=o?qSQ{B=|SFIRRDsq;7l1Y9v_@&tGqC%!lnHis>T2N9m=C$2@;w_ z^+;FOD>I4ZAo?0b*?V#e98SFpjbTVS)|kdGf@tR}Nz^WioK`NZX5w)1oC!#jE zPq7$^>xRarvqvHl=?pL3#T|tL2BrLonS5*xIyySL+@B2+2|3A?UYk~m&a{{dZhx&T zruC16i z&UA@!_&+F=smkQVsBlN*WQ9Xxa%13F(&1Z13#s zU%F;}i+Y(s4iZc3$OVvWr$SHwh%aYTBXYd)Hqr9Zmx56seO76J7Z8GjL>2~Eg3slj zPr_Jdq0}S|7wAHj?_NeFecEHx1i?;S;@g^NP(;Yqn!C$b8r}e}C@eu-ocI&)0LI~3 zw-)_g2Jf#F{E4_B1A0f|OF`1@j)h)Vj~oJU*t~wKQ|P%HRd^9N-V<}=!2ju&K@!j9 zjp~aPc`IoI^6w^*M)hQ+%gduP^P-n=Y^;`r{23Gyt$)lP{-dB}s6!ub)9OOT)i}Y* zVcD9jCl=s!*c*!L!26s2Su3jyr&mY(KWAXeF3F$j*cznNM^Lcq^-oJ7QfL^x$Rb0P z^%*mGxBlR_p2Kpo!DN_s*-_ve^j0cw5Pe>gTC-tD0PWPRL8=jH00oo`f)Rf=fDF@)K>fEsN0h#kX+p~RuQ^DQ8s=Zu*o z+BN~{cxkSOzenCFUhhERjdiIg85Jex2(dPA4IlB`L)hgayMcpB4)NF{UEemXC@cG0 zospR2OEptAO|Aq0(J$hsIIW@dtaQ007fQ4%{rwv5=(ffwyEPL3|Jb}-<_}xcy0JN` z!=ozMPhtaExU`0gZ{P6nizF;3I}x9;!Olx#Mjzt-*E}7Yv6M5K04IfD{+ir91}m9L zXO=QS*8Hpa&bQEG)YCAO-y=Vh44mmbtsfDZ3M~90a+d>jmDGMD5bwrFVy}FuB9u)a zWr}E5bP2(=xW?9n99G@lHb)hkMH_!{*ytW#E_XwBxE4@I`@&5l)`FR38$aZ+7`@r|8!G8YTr#1DiEs%9 z-G3`nRp1~B?|XP~FH`M4p3ZUnY~@BWIQNZ~k>>2==hB|&N^8i6#cn85p=Q}S1JBpB z!r6V72hCQRjD>72vhWJijpr$ae=XNduFS>_`15%eFb9Wn|1N>5eDjg~nYdco$@ml+ z{`W)WBpT@b)@))5&ddlE3d~Bz+2t{x*w+6949Q1w0D?%Mjs7)@l)V#MOrc~(K zvO)C$ozzGJVcC5)N=-+&y1faK>mW_;4=v9ogwf+LA!D=#$5j$!k)?22H36`%?%Ohy z8X3GQhnuALhoarOhWs^@ZB8KKCq_zb zCs|~E7+hAZ&@O9YHo6`W9PB}aKTDL^y!^(v4_*Ko|J{P@(dtIv^`8d9H|n@PQup>d z2?J3&pG)cFN!0K~%q*yB;a`uX*{BD(Y*VsD?S=H~9e_IHwK5H>bOJC{_)&X#x1|`g z8v|~Vm?flgJ}{xRpCpNkl(&`i7{~^^CrAm1(v*M-9Vs2|GAUv_2*y5Kx&wdq4R1#m2aJZ%ZgJ z{u5?24SLb+q!4+PQUQYh^!K! zG`iA5CuJRn&5J+m@GgZN+fIfVmc7RQKCV=nHN)H%YyxFxQb^gVGI`Vh!b>NSn1p5QAU1~n8Suz88Oekwz z<|~=Ltr$~&*oSiLa&z3?Rt)b-N3O4co+j}MR7&}s96ot;2L6hxU@4;LBzAOGI_>|X zpGq{C1pSZPfYD$JJG+C8ON>er%#JN~gHkHi5iiI1N0h%|@aal2>(^JovP(FPL)E|E z@iTeS0J^@FTYy6&FC}|1hT8IQa6%3Hr|_GI^g4Yt%~lwgsWEC=`ze>NguuT5?=73Q zBfl-{F%-get5dLFZzw>NSi`AIIkT!874UG)?YzQh7CBxMm5V=_mqIj)c>X?`c{X@- z@S|VwYkE$%oyerS$>y*i6Ak-GqLnEy2Qq6T8s(NTS?vPN*a)M#sB(dsUMie(vB9rs zjk|4Yb3IA-62wF349^&DjB07DG5u52XTPQQa7V8LbJPEoGFNY~I7SMa8_FeXH3(7W zKTxLIp;v8>rOhvSI~Mqr1QL~INqed%pN5W`v+i0N%^2;I^-Au<+)9cO>NTK9NZTo@ z`CAQ`h5c$AnNG(lVoLN$HY@Z=+`vN6r&~({Tl)GLi~kqVLT;H7E>>W~5AA)Iv5obD zmm(C40S9{_%F+8pTuGiPfBENVF((XdDHgqd!7+&T5q^DiC<7$G)7}4i$W1@#3HVkp z_Sw8hHU8QVk*xrVXIa|>gq*ZMoTCbSW1G2K#BAQtieMM5T%P=B7CYYk$&&t z3B3t!QG6?Z00FS`G7@)T0M^CC=Kv#jWE6uy%v*r=J^!yYBpd4M3jcJi+>ZEWiSZ)e~>Y&KI!ZTsaU*KCxHxDm>@(4UV^q}lRqSzUoK*DlZjrpj>S&} zt>M#y68h$v{}AGA{4=v6%Yvm$p&=uTIotC>9i#;-0|Yt^7FQ8YGk@sis)WtLjn^lkQIW}@-W_I-Ub3Eon9 zOZbd!G!em0S*x3r_F(uwX*QobkXHoA$uV!7o$iE4mw83C3POLP@C0G13^$6oXxJLW zO+KS`v34&^tnQCfW(Y*^Q>7v5&v$b*V!MC$0M6`X!~0kLaQy{iKC|!=0J4$=f9^pt zJ-eza`66Ih@cRUBzOg`@O8-ZJ=HMAo>2_uD5O}J}w@${E7$<3!a)e>UKx*QaB$~RRW$Td)Z?%xu2H(2_-_wt)#JDt#MhDHFvhhMm0N-q;qW0>v6TtWDY4y z76cyME*wKYjc}8tz;bY72I44kMQe2*dR3?*yYxAY?R(9$r7&cL4d2zLkdssSuk;xj zQvcrmotYGp|84?3i$J|V%$}Zvdb?c5-phkmi4wwf_4eKtgFCubeYiY`0y;K59oP8! zt08Ec8%36yzZjc=HXWs0u-%LL-A6lTfAs;8>(;lz;~jY<(HO7C+#;G&RLGgfT)J26Z zBHuYfve2f!P{;}rjrXBe7$Qi*I_ti;U^fk-Ci(qG77Kyzp;qAK@>@)*Q5eOhP@p*8 z7$O|lo?P3$I52uX?FeC*Dla#&(y)9czus=#e%@U+BALv@z&@C3f!QMj2&XR~X;dC+ zjHyNXv9Lzh(V%#A;(}w{QG@XIb(}2=S_sz{tj4Gye^1Ja5c)PH9t+S#MyssYXUy!D z1N>kyDd@wu3igLCJ#~Lm5VPhl3f3cw2xk@9N6Nl}L z@o+fr$}UzwF+n%Ei}i~km#9PMmAEM0z%va+PG#B|4AO$Lc1(SvRMq$XUUj324o$?W z%5yke=+xgGEy$q>JIqDGd@~oDeZ!bOoxJL*3>CF2^RuN-1#f@6o(pb-jmS1DqOc@J z5t5}{x5|zm6UjS#-*F`ye_sR2zk7(n|Il6(aO(Jmy4HyBnCi=R+K8Zc3|b;><3s^o z>W7*?;rJ;DZ(VS~Gg7LYhN4Y!U1tSJC;?MKK^%|h4Kkl+BnMtgnPs*6-&3LAve%e^ zA8?}BHUA{oygsVC`{KY7g8w|fn04OB&ct2Z_t1@8}&Bg_4pI8yj1B4sbU6q;q%Oc)BH6RVrWD ztcbLd_l#tTS`ZDw4SN?DJ7IIfImSO>u7(@mm1^#A_N!^M$ByS}5J2CgRZ3Laoa1yz zQEmyq=3JAG-N(+6;_o&zaX7+}i7ueLH8#HqbW9&bR)wT3Ia<>6ejFm#@;+bq>_D6u zYVRyG^F{MBL=whv>AW;fI~aMm+>Wb$EK~jS>9jb!#D8vG!fSU*zloHld52?@L43vX zubKYRm6RZzAhZ_{W7m_Cz)Q%_@kAlrW_(gJTPvJxL#5s5UcybDP3_Cc z0sP9D{5LjQl!#W@aa{%U#jR?2%JlI=TdB-E1PEEjfSqd7HUj-hMfV+d8fIyvgZ~fZ zt{QT=)(yb9L`PDfPy=vdsN<&id=VA-7|bMV*UGM=BJDNBf4UxOeXww;tO|RW@Exmt zpgTtX$FlbHLw%qMr|;Ia*noLmtB-BDAl;P)q~){}@aUN9_hny;F5gA9U9}(DILHvh z0PBAIlptIX=%s07tLPVf%>&jscP8&?i9dZFxq)HLHX1kdM--g~fk_+h_Q)AjJT{{r z`5*3AR)Xpufee!=DDz(EDYIJes_H(&W!nhkyb-=ot}Rce(h9JX^FsX(_|FDB$wv62 zC8kDeU9;CTImVl$c(UwNgv*h~wLr7m^~&>+lkT?9%JWm(5X*Mue4fKX|)?u*DC$z#PWH1@XF)S5U_VUy9E{NX+%@8I!-QHTgRw1eN~F_*YM6$ z(muC@T>lQBtHq9KRh`&NHlv{Y=?lqkZ9#a2dTLwe8D0n=SUIVv5#=bqJ;zfAWIGszCo>OkA9dg!ZoxT% zdda}BIBY0$cjt{Cx;V$}H>5@!@cWa%*l9hlL&%$s#@+n(PR~JDnUKs6wxwV)`8Uzk z^WNSWOHCjUHu*~}z}tswN41A#mvy0JeVTWO@5ysP;4gnb-wlf7*5Z*AvewU6v&eIGjk2&L<_j- zxSsZM4ahan{A?lbAg8>-jp#Rt+?oR`R0z+2>J$RJTLe^sEsjUS!ooKd=5*X55hDt8 zaXzdVcS2$s=7d`?f45#Xz%$1bLN{&MBZqJr|p z=4a6t>8?CkNNOO$Elh@3bVs@=t9>jwd!U}eD|hAd$xk&baV%D=kWfnsTL{s_4TQi zY1TR(E(8Y$bC|;bL!PZzv}s;AsheAF^0StW_9Cv7zS3l#*278Df8(uYR_IS?Fz)J` zSQQ_6Sy|JCP8ImP_qz4~Qs0D|&P+-oEHV4MoL-Cq=QgnH>KZpoD(yDK{+ z&>N^yXb8?m5gJhbUqr6(z^JsGQA~SXFlR_$8~8KAR2K`uz}Prnoe{QwsaeL!^ye0G}y(Nq%R;^IhdcGJAy*FxxCQKCq7 z8tEzEa-_&E?TQyxO< z{w$FMIgm}i{}IF|Ae9A4ve*LB2D$=Zds~L*jCDwKtxY7yIpZu)-;p?!rhMPqd;12k z!DsL*RH4PT2iiN2=h9gIT7EL4S?5D|lYj$83FM^xVV_@M&uY(IQao+YN(A8H&?FWM zkKzA^fb=|LQN0-D*P;&1e8&aKk*oYpCrpL0?tHH(@H2AbhPLb)wdmsqx6W9x!TZfF zuj)HceLFs-0Cgax%Jkiqfq{W`^_%>NAs&lb=y3Dp?@&-DnuzCS-vWA`l$4a5oSc}L zn3PnTS^)e7K?JMG#LO&&<+1CiZ(v~H=7t-!-|n9+aLPP|q~GhUddd37$Fahde*LAP zFcKHVV)ds+v-Oe&;=}RMKw(Lg4(UHiRzV$>zdMLoZvQa!u&^anpX&5 z&dL?6Y^!?6M|QZzSwCZPZJlZHDJ+vw{1B_vto2ktm+~q!pTn*czJ<-e)ymjxcgN3v1EE(ij3Pr~ z;EhpK@I3BRRW^~x^@*m0ygq@DVq|d@|1t>X2#fh>;EjxX1XPYwjYF=Iz@ot;+)ct#B0%<@A;QXk-yyQYo(D+gU$Nz7U^Zh*>iK`8@8T0&itT z6TBjG+!QakStagpyCyRQahj^S8xnWISV!5K}ehkUf z8J9j69JW1y<+VDJw&QPw9AL6{YnRE?t~6}12IwS>Iv=P<%E`;e+NDe}tiCO7u$z4} z@7JaK3C~3(IJ(CHP z!_bgHigSNKc{}lk@za2y!A>mtj>J4Jb)9R!Vab$!jrJb<4<#~+is0@DBJF4 zDkdrUfkcKZEY$Y?upS=d$!8D5c!uK4#`rf}wbBdCSeAOpXLY?=3&fVkS-T4X!09&d0;$-$p}M zhktJoMTXK#B0U(&q)iFH0u#)i@KDI#!gmB>5NFdi?Uy$@vky}@$>#Nh4p<)^H6O#6 zNorlff{7k4E4T6qWX3g} z_7N9}(C3vmA2n$=J4Sni`Ek+cq^EFNzVL0Mq%AhuoBRMBWFf_OaLj6TR}9UzUDc`* z^9HPH9)8%R*u(nYcRgMyE_yfUu~w-`Y$<; z-R5=s^J57B8~1=OVB%WM@IhQ5z3_smU*DPcpwY>e&W|0Bj@*twIVH5BZ(HK8X*O-~ z>^=Z3tgOlbDI~&xT<1hErC2AR$u+Go`G@WK;Htq~26J;jF7E3(lf7 zg+2cE1$a*X1dwK?jMPlDE_d93YDqx3qDKcrOSiN!UrX;goYgnFkvRpXY|@Xg)Mpmh zm~WgP&#waT^)e9aXfb-xyH8RKbHHrE#06v77C*`MHk3@G(K@tbYE3vBGQVwJxV2O) zVS@J79-M!VfNd7>C@D~hii%QEQ32(nG^sXS!8GX&c3XoJ6ADfL+IYZU+Z2n!A|lGQ z8h?MIUA6qhZ^cgZ57MYbMnu#_J&2CN^2QPWpO(?_!r9x~U%Co} zyweG4h*Q+foH1L=1-s^P7$(?!Yb}~F17f=)#yFsFP5{&k3<|2U$_g1786g#L#bxWg zM3nG*ct!ID98-3C>%zzmg%2==Kv3)vKl$v*XsUk)*LJC^$LO&CQ5g0wE)b3m;Y9P7x7+n{3plB)=BL*qmm+>BGG(L&uA1 zs-MGE@Pqh9oedomKGYTbQJOw7$XP!*!dpT;Nn6Y1fLiy3MOkEJJX~48@MX;*Y7Ab; zn8&C3j+%#ATr6g#7CAXNK-DdE0oZqP^07|p3{}41FM6`b+FMd!y%)3u;8Ib|w9IwUwT^U=cWaqoM1qKkiHWSN zEQ6|s%F2&ILXq@=B7J$W@B47UM#RPAkE!U$zutxr)IHONREETk#z@E5=y6JM7tX`) zyB9m^l9I?ToLt;;s>dYTj0cFyqXmd0bO~!lu1kte=XUwbge6D?dwl-6@U?nA7cvLk zO_xwXq0%FH11?>gn>+#D=djN^Px#4xE%OsN`NLXf1hE5L!A)(pPR)5YCu zW|9sh1ZDElF5yS%CT%?RooO19#0Ow~(%o}&iH@x<)t&4OHYX5hk#qC}Q?e7eE;ta342Vc7xPc4Dd7LsYxwX24c|O?6b18SOY|?HKl`b`(CDvAk!JuwSLh43kk6ZQTWa%?!v9N0p-I<4Qf^mhi)w*b%p{3MJcsQk%1 zRE4|d*W_L*TBp!R_BJX0okyvlLor|}`D$nDN!w}D$kcZ->!sSwSf)hhfwY_MK6UfHNASy}c;d9oufd81e# z==+q&A-*iw=EL@-Vk|t9T(qn&q)+=c&;3-jUo1qIX;0=HqK+w&JE*d->78V>Tt0lZ z6TV{6*YfKds<}aUkYr3vs8y@YAk60#C$HbAIQZ))7tf;TagF?v#bo1HtCSxhJIP#} zOqxEjrzdE7Gr}?3_$kHXF%%V=X=xnkMn_qW6&&bF4iSNw)uxcz0KQ>jA*aYNbMSqr zrg_SzuC?1(lQB)lRT!zB()h!uMY@$Nn3th7DRt%p9tBB9dC)GsSf*>vlH!d+i0ni% z@7n-l@RL+Ck^`xzT#mW_I1zhqAf n7_ApG!OSsplit has been inherited by our class NVP_LIST. Feature split includes code to create and attach feature sublist which is typed attached like Current which in this case means attached NVP_LIST. To do this creation, split uses a creation procedure make_sublist. + +Now here's the rub: NVP_LIST has not named make_sublist as a creation procedure: + +create + make, make_from_string, make_from_file_named + +So if we go to the create part of NVP_LIST and add make_sublist to its list of creation procedures, this will fix the problem: + +create + make, make_from_string, make_from_file_named, make_sublist + + +So, fix any problems that arise out of turning on full class checking. + +==Enable other project settings== + +The second step in conversion of existing software is to change the values of the other void-safe related project settings and use the void-safe configurations for any delivered libraries and precompilations. + +In the project settings for the target in which you are working: +# Set '''Void safe''' to either '''Complete void safety''' or '''On demand void safety'''. +# Set '''Are types attached by default?''' to '''True'''. + +{{note|Remember that during a transitional period starting with V6.4, there will be multiple versions of the configuration files for Eiffel libraries and precompiles. For example, base.ecf (non-void-safe) and base-safe.ecf (void-safe). It is expected that in the future there will only be one configuration file (e.g., base.ecf) that will work with both void-safe and non-void-safe client software. }} + +If necessary, remove Eiffel libraries and any precompiled library that your project uses and re-add them with their void-safe configuration files. Because you've set your target to void-safety, when you click '''Add Library''', you should see only void-safe configurations by default. +You will see a check box on the dialog that you can uncheck if you want to see all available library configurations: + + +[[Image:VoidSafeAddLibraryDialog]] + + +Now do a clean compile. + +If you've replaced a precompiled library that you have not already built, EiffelStudio will offer to build it for you on the fly: + + +[[Image:VoidSafePrecompileOffer]] + + +Now you should see error messages representing any situation in your project in which the compiler determines that it cannot guarantee void safety. + +This is what our legacy system produced: + + +[[Image:VoidSafeErrorList]] + + +==Fix the issues== + +Next you fix the problems that the compiler discovered. The compiler errors concerning void-safety typically will be of three varieties. + +# VEVI: violations of the '''Variable initialization rule'''. An attached variable is not '''properly set'''. +# VUTA: violations of the '''Target rule'''. The target of a feature call is not attached. +# VJAR (and other related codes): violations of attached status considered in conformance. The attachment status of the source of an assignment (or an argument to a feature call) is not compatible with that of the target of the assignment (or the formal argument). + +Let's look at some specific cases and how fixing them unfolds. + + +[[Image:VoidSafeVEVI1]] + + +There are two errors like this in our legacy system. They are probably the most obvious and easiest cases to handle. + + +feature {NONE} -- Initialization + + make + -- Run application. + do + ... + end + +feature -- Access + + my_nvp: NVP + -- NVP for testing + + my_nvp_list: NVP_LIST + -- NVP_LIST for testing + + +Here attribute declarations for my_nvp and my_nvp_list are made. These are assumed to be attached because of the project setting. But the create routine make fails to create objects and attach them. So by adding those creations, as shown below, the compiler is satisfied. + + + make + -- Run application. + do + create my_nvp.make ("Hello", "World") + create my_nvp_list.make + ... + end + + + +In second case, there is also an Initialization rule violation (VEVI), this time on Result, in this routine: + + + at_first (nm: STRING): NVP is + -- The first found NVP with name matching nm. + -- Or Void if not found + require + nm_valid: nm /= Void and then not nm.is_empty + local + tc: CURSOR + do + tc := cursor + start + name_search (nm) + if not exhausted then + Result := item + end + go_to (tc) + ensure + index_unchanged: index = old index + end + + +Here we cannot just ensure that Result is attached, because, as indicated by the header comment, Result is allowed to be void by design. + +So the least impact to this routine will be to declare its type as detachable: + + + at_first (nm: STRING): detachable NVP is + -- The first found NVP with name matching nm. + -- Or Void if not found + + + +The same change is made in other routines that can return void by design. + +The change to at_first satisfies the VEVI issue in at_first, but it introduces a previously unseen conformance issue (VJAR) in a routine value_at_first: + + +[[Image:VoidSafeVJAR1]] + + +value_at_first looks like this: + + + value_at_first (nm: STRING): detachable STRING is + -- Value from first found NVP with name matching nm + -- Or Void of not found + require + nm_valid: nm /= Void and then not nm.is_empty + local + tn: NVP + do + tn := at_first (nm) + if tn /= Void then + Result := tn.value + end + end + + +The problem is that the local variable tn is declared as attached, but we know that now the result of at_first is detachable, making this assignment invalid: + + tn := at_first (nm) + + +Here the '''attached syntax''' can fix the problem and streamline the routine: + + + value_at_first (nm: STRING): detachable STRING is + -- Value from first found NVP with name matching nm + -- Or Void of not found + require + nm_valid: nm /= Void and then not nm.is_empty + do + if attached at_first (nm) as tn then + Result := tn.value + end + end + + +In this version tn need not be declared as a local variable. Remember that the attached syntax provides a fresh local variable, if the expression is not void. + + +==Code patterns== + +===CAPs=== + +===The '''attribute''' keyword=== + +===Using generic classes=== + +===Using '''check''' blocks=== + +==Transitioning steps== + + diff --git a/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki b/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki new file mode 100644 index 00000000..bcb5e696 --- /dev/null +++ b/documentation/current/method/void-safe-programming-eiffel/creating-new-void-safe-project.wiki @@ -0,0 +1,73 @@ +[[Property:title|Creating a new void-safe project]] +[[Property:weight|2]] +[[Property:uuid|92cea2e9-b094-6380-2c5d-1cd1eb3038b4]] +{{underconstruction}} + + + +=Creating a new void-safe project= + +Now that we've been introduced to the Eiffel void-safe facilities, let's look at what it takes to set up a new void-safe software project. Here we'll look at the void-safety related project settings and how the can be used. Then we'll look deeper into the use of some of the void-safe tools. + +==Project settings for void-safe projects== + +There are three project settings that are related to void-safety. These settings can be set with great granularity throughout your project to allow you maximum flexibility, particularly when including classes or libraries that are non-void-safe or that have been converted to void-safety, but must do double duty in the void-safe and non-void-safe worlds. + +===The ''"Void-safe"'' setting=== + +The '''Void-safe''' setting determines whether and how the Eiffel compiler checks your project against the void-safe related validity rules. + +This is the essential void-safe project setting. It can assume one of three values: +# '''No void safety''': No checking against any of the void-safety validity rules. +# '''On demand void safety''': Validity rules are selectively checked. Attachment status (VJAR/VBAR and related) is taken into account when performing conformance checks, but initialization rule (VEVI) and the target rule (VUTA) are checked only for attached entities and attached call targets -- i.e., detachable cases are not checked. +# '''Complete void safety''': Complete checking against all void-safety validity rules. + +So, for a new void-safe project, you would want to set this option to either '''Complete void safety''' or '''On demand void safety'''. + +===The ''"Are types attached by default?"'' setting=== + +It is this setting that tells the compiler how to treat declarations which specify neither the detachable keyword nor the attached keyword, for example: + + x: T + +A value of '''True''' will instruct the compiler to treat x as if it were declared: + + x: attached T + +A value of '''False''', and x will be viewed as if it were: + + x: detachable T + + +In a new project, ideally all of your declarations would be of attached types. But of course there are some occasions, for various reasons, that you must or should use detachable types. + +So, for a new void-safe project, it is recommended that a value of '''True''' is used. + +===The ''"Full class checking"'' setting=== + +This setting instructs the compiler to recheck inherited features in descendant classes. + +'''Full class checking''' should always be set to '''True''' when compiling void-safe code. + + +==Void-safe libraries== + +As of EiffelStudio version 6.4, the majority of the libraries distributed with EiffelStudio are void-safe. + +During a period of transition, there will be different Eiffel configuration files (.ecf's) for non-void-safe and void-safe projects. If you have set the '''Void-safe''' setting to check for void-safety, then when you add a library to your project in EiffelStudio, you will see the void-safe configurations by default. After the transition period, it is expected that there will be only one version of the configuration files for each library. The single configuration files will serve both non-void-safe and void-safe projects. + +==Using non-void-safe libraries== + +==Using the ''attribute'' keyword carefully== + +The keyword attribute is should be used with some care. You might be tempted to think that it would be convenient or add an extra element of safety to use self-initializing attributes widely. And in a way, you would be correct. But you should also understand that there is a price to pay for using self-initializing attributes and stable attributes. It is that upon every access, an evaluation of the state of the attribute must be made. So, as a general rule, you should avoid using self-initializing attributes only for the purpose of lazy initialization. + +==More about CAPs== + +==More about the ''attached syntax''== + +==Stable attributes== + + + + diff --git a/documentation/current/method/void-safe-programming-eiffel/index.wiki b/documentation/current/method/void-safe-programming-eiffel/index.wiki index 044d0c7c..8a37c0d5 100644 --- a/documentation/current/method/void-safe-programming-eiffel/index.wiki +++ b/documentation/current/method/void-safe-programming-eiffel/index.wiki @@ -22,46 +22,5 @@ The result is that we must consider certain questions: # What do I need to know to produce standard Eiffel software? # What do I need to know to convert my existing systems to be standard? -Let's try to answer those questions. - -==Background== - -The primary focus of Eiffel is on software quality. Void-safety, like static typing, is another facility for improving software quality. Void-safe software is protected from run time errors caused by calls to void references, and therefore will be more reliable than software in which calls to void targets can occur. The analogy to static typing is a useful one. In fact, void-safe capability could be seen as an extension to the type system, or a step beyond static typing, because the mechanism for ensuring void-safety is integrated into the type system. - -===Static typing=== - -You know that static typing eliminates a whole class of software failures. This is done by making an assurance at compile time about a feature call of the form: - - x.f (a) - -Such a feature call is judged acceptable at compile time only if the type of x has a feature f and that any arguments, represented here by a, number the same as the formal arguments of f, and are compatible with the types of those formal arguments. -In statically typed languages like Eiffel, the compiler guarantees that you cannot, at run time, have a situation in which feature f is not applicable to the object attached to x. If you've ever been a Smalltalk programmer, you are certainly familiar with this most common of errors that manifests itself as "Message not understood." It happens because Smalltalk is not statically typed. - -===Non-void-safe software=== - -Static typing will ensure that there is some feature f that can be applied at run time to x in the example above. But it does not assure us that, in the case in which x is a reference, that there will always be an object attached to x at any time x.f (a) is executed. - -This problem is not unique to Eiffel. Other environments that allow or mandate reference semantics also allow the possibility of non-void-safe run time errors. If you've worked in Java or .NET you may have seen the NullReferenceException. Sometimes you might have experienced this rather poetic sounding message: "Object reference not set to an instance of an object". In Eiffel you would see "Feature call on void target". All these are the hallmarks of run time errors resulting from non-void-safe software. - -{{note|If you need a review of difference between reference types and expanded types in Eiffel, see [[ET: The Dynamic Structure: Execution Model|the chapter of the Eiffel Tutorial dedicated to the Eiffel execution model]]. }} - -Of course this is not an issue with instances of expanded types, because these instances are indeed "expanded" within their parent objects. But we could not imagine a world with expanded types only. References are important for performance reasons and for modeling purposes. For example, consider that a car has an engine and a manufacturer. When we model cars in software, it might be appropriate for engines to be expanded types, as each car has one engine. But certainly the same is not true for manufacturer. Many cars can share, through a reference, a single manufacturer. - -So, references are necessary, but we want them to be trouble free. - -==Void-safe software== - -Void-safe software, then, is software in which the compiler can give assurance, through a static analysis of the code, that at run time whenever a feature is applied to a reference, that the reference in question will have an object attached. This means that the feature call - - x.f (a) - -is valid only if we are assured that x will be attached to an object when the call executes. - - -{{info|This validity rule is called the '''Target rule''', validity code VUTA, and is the primary rule for void-safety. In the following discussion, you will see that other validity rules are involved, too. You can see the formal definition of all validity rules in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm ISO/ECMA standard document] available online. }} - - -Once we have committed ourselves to this validity rule, we must have a strategy for complying with the rule. - diff --git a/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki b/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki new file mode 100644 index 00000000..6464e71a --- /dev/null +++ b/documentation/current/method/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki @@ -0,0 +1,268 @@ +[[Property:title|Void-safety: Background, definition, and tools]] +[[Property:weight|0]] +[[Property:uuid|689f62b2-5675-5ab6-cd47-d891cf3d484d]] +{{underconstruction}} + + + +=Background= + +The primary focus of Eiffel is on software quality. Void-safety, like static typing, is another facility for improving software quality. Void-safe software is protected from run time errors caused by calls to void references, and therefore will be more reliable than software in which calls to void targets can occur. The analogy to static typing is a useful one. In fact, void-safe capability could be seen as an extension to the type system, or a step beyond static typing, because the mechanism for ensuring void-safety is integrated into the type system. + +==Static typing== + +You know that static typing eliminates a whole class of software failures. This is done by making an assurance at compile time about a feature call of the form: + + x.f (a) + +Such a feature call is judged acceptable at compile time only if the type of x has a feature f and that any arguments, represented here by a, number the same as the formal arguments of f, and are compatible with the types of those formal arguments. + + +In statically typed languages like Eiffel, the compiler guarantees that you cannot, at run time, have a situation in which feature f is not applicable to the object attached to x. If you've ever been a Smalltalk programmer, you are certainly familiar with this most common of errors that manifests itself as "Message not understood." It happens because Smalltalk is not statically typed. + +==Non-void-safe software== + +Static typing will ensure that there is some feature f that can be applied at run time to x in the example above. But it does not assure us that, in the case in which x is a reference, that there will always be an object attached to x at any time x.f (a) is executed. + +This problem is not unique to Eiffel. Other environments that allow or mandate reference semantics also allow the possibility of non-void-safe run time errors. If you've worked in Java or .NET you may have seen the NullReferenceException. Sometimes you might have experienced this rather poetic sounding message: "Object reference not set to an instance of an object". In Eiffel you would see "Feature call on void target". All these are the hallmarks of run time errors resulting from non-void-safe software. + +{{note|If you need a review of difference between reference types and expanded types in Eiffel, see [[ET: The Dynamic Structure: Execution Model|the chapter of the Eiffel Tutorial dedicated to the Eiffel execution model]]. }} + +Of course this is not an issue with instances of expanded types, because these instances are indeed "expanded" within their parent objects. But we could not imagine a world with expanded types only. References are important for performance reasons and for modeling purposes. For example, consider that a car has an engine and a manufacturer. When we model cars in software, it might be appropriate for engines to be expanded types, as each car has one engine. But certainly the same is not true for manufacturer. Many cars can share, through a reference, a single manufacturer. + +So, references are necessary, but we want them to be trouble free. + +=Void-safe software= + +Void-safe software, then, is software in which the compiler can give assurance, through a static analysis of the code, that at run time whenever a feature is applied to a reference, that the reference in question will have an object attached. This means that the feature call + + x.f (a) + +is valid only if we are assured that x will be attached to an object when the call executes. + + +{{info|This validity rule is called the '''Target rule''', validity code VUTA, and is the primary rule for void-safety. In the following discussion, you will see that other validity rules are involved, too. You can see the formal definition of all validity rules in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm ISO/ECMA standard document] available online. }} + + +Once we have committed ourselves to this validity rule, we must have a strategy for complying with the rule. + +==Elements of the void-safe strategy== + +Here are the tools of void-safe trade. They will each be addressed in more detail throughout the documentation that follows. As you look at these elements it helps to try to think about things from the compiler's viewpoint ... after all, it is the compiler that we expect to give us the guarantee that our code is indeed void-safe. + +First let's look at a couple of approaches that won't work. + +It might occur to us that we could enforce compliance with the target rule by simply eliminating the concept of void references. But this would not be practical. Void is a valuable abstraction that is useful in many situations, such as providing void links in structures. So, we must keep void ... but we want to keep it under control. + +Another thought might be that we could just have the compiler do all the work for us. But would be impossibly time consuming for the compiler to investigate every conceivable execution path available to a system to make certain that every possible feature call was made on an attached reference. + +So, all of this boils down to the fact that we have to take some actions that help the compiler along. That's what the following are about. + +===Certified Attachment Patterns (CAPs)=== + +We know that in the context of certain code patterns, it is clear that it would be impossible for a reference to be void. These patterns are identified and we call them CAPs, short for Certified Attachment Patterns. Here is a very straightforward example expressed in a syntax that should be familiar to all Eiffel developers: + + if x /= Void then +-- ... Any other instructions here that do not assign to x + x.f (a) + end + +Here a check is made to ensure x is not void. Then as long as no assignments to x are made in the interim, a feature f can be applied to x with the certainty that x will be attached at the time ... and importantly, this can be determined at compile time. So, we say that this code pattern is a CAP for x. + + +It is important to understand that in this example (and with other CAPs), x is allowed to be a local variable or formal argument only. That is, x may not be an attribute or general expression. Direct access to class attribute references cannot allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. + + +{{note|You will find a more detailed discussion of CAPs in [[Void-safe programming in Eiffel#More about CAPs|More about CAPs]]. The current list of CAPs appears in the [[Catalog of Certified Attachment Patterns]]. }} + + +===The ''attached syntax''=== + +For the purposes of void-safety, the '''attached syntax''' does double duty for us. It allows us to make certain that a reference is attached, and it provides us a safe way to access objects that are attached to class attributes. + +We noted earlier that this code + + if x /= Void then +-- ... Any other instructions here that do not assign to x + x.f (a) + end + +creates a CAP for feature calls on x, but only if x is a local variable or a formal argument. + +By using the '''attached syntax''', we can perform an '''object test''' on a variable. That is, the attached syntax is a BOOLEAN expression which provides an answer to the question "Is x attached to an object?" At the same time, if indeed x is attached to an object, the attached syntax will deliver to us a fresh local variable, also attached to x's object, on which we can make feature calls. + + if attached x as l_x then + l_x.f (a) + end + +In the example above, x is tested to make certain that it is attached. If so, the local l_x is created and can be used safely even if x is a class attribute. So, the attached syntax, is really another CAP, because it provides a clearly verifiable place for the application of features to targets that are guaranteed not to be void. + + +{{note|The attached syntax has other syntax variations as well as other uses. These will be discussed later. }} + + +One way to make sure we comply with the target rule would be always use a CAP or the attached syntax every time we want to apply a feature to a referenced object. That might work, but it falls among the impractical approaches to the problem ... it would break a very high percentage of existing EIffel code, not to mention cluttering things up quite a bit. + +===Types as "attached" or "detachable"=== + +Rather than trying to protect every feature call, Eiffel allows us to declare variables as being of '''attached types'''. This is an important extension to the Eiffel type system. + +In Eiffel prior to the introduction of void-safe facilities, any reference variable could be set to Void. So, all variables were considered '"detachable"'. + +The current standard Eiffel supports a mixture of '''attached''' and '''detachable''' types. When a variable is declared of an attached type, as in the following example, then the compiler will prevent it from being set to Void or set to anything that can be set to Void. + + + my_attached_string: attached STRING + + +It is easy to imagine that the more declarations are of attached types, the easier it will be to guarantee that a call to a void target cannot take place at run time. In fact, if every declaration was guaranteed to be of an attached type, then that would be all that was needed to satisfy the Target rule. + +However, it wouldn't be workable to have only attached types, because sometimes it's important to allow references to have a value of Void. + +When it is necessary to allow Void as a value, a declaration can use the ''detachable mark'' as in the following. + + my_detachable_string: detachable STRING + + + +This doesn't mean that on every declaration you must put either an ''attached mark'' or a ''detachable mark''. Declarations that are unmarked are allowed. Whether unmarked declarations are considered attached or detachable is determined by the value of an EiffelStudio project setting named '''Are types attached by default?''' This setting can be set differently in different parts of your project giving you fine-grained control, which is particularly useful while converting existing software or mixing libraries of differing void-safety levels. + +In Eiffel then, all declarations will have types that are either '''attached''' or '''detachable'''. + +This means that we need only use CAPs and the attached syntax with detachable types. + +===Initialization rule=== + +If we have attached types, then we can assume variables declared of these types, once attached, will always be attached. But how do they get attached in the first place? That's what the initialization rule is all about. + +The rule says that at any place in which a variable is accessed, it must be '''properly set'''. A variable's being properly set has a precise, but not particularly simple definition in the Eiffel standard. + + +{{info|You can find the formal definition of the '''Variable initialization rule''', validity code VEVI, and its related concepts such as '''properly set''' variables in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm ISO/ECMA standard document]. }} + + +Still, it's not too hard to understand the basics of initializing variables of attached types: + +* For the initialization of attributes of a class, we can apply a rule similar to that of the initial evaluation of class invariants ... that is, everything must be in order upon completion of a creation procedure. If a class attribute is of an attached type, then each of the class's creation procedures is responsible for making sure that the attribute is attached to an object upon its completion. + +* A local variable is considered properly set if it is initialized at some point '''preceding''' its use in any execution path in which it is used. So immediately after its create instruction, the local variable would be considered properly set. But if the create occurred in the then part of an if instruction, the local variable would not be properly set in the else part of that same if instruction: + + + my_routine + -- Illustrate properly set local variable + local + l_my_string: STRING + do + if my_condition then + create l_my_string.make_empty +-- ... l_my_string is properly set here + else +-- ... l_my_string is not properly set here + end + end + + +* A variable is considered properly set if it is '''self-initializing'''. What it means to be self-initializing is explained [[Void-safe programming in Eiffel#Self-initializing variables|below]]. + +===Self-initializing attributes=== + +A self-initializing attribute is guaranteed to have a value when accessed at run time. Declarations of self-initializing attributes are characterized by the use of attribute keyword. The code that follows the attribute keyword is executed to initialize the attribute in the case that the attribute is accessed prior to being initialized in any other way. So, the code in the attribute part is a kind of last resort for initialization. + + + value: STRING + attribute + create Result.make_empty + end + + +In the example above, the attribute value will be attached to an object of type STRING, in fact, the empty string, if no other initialization occurs before the first access of value. + +===Rule for conformance=== + +You will remember that the Eiffel type system dictates that an assignment instruction: + + x := y + +is valid only if the type of y is '''compatible''' with the type of x. Compatibility, in turn, means either '''conversion''' or '''conformance'''. + +The fact that all types are either '''attached''' or '''detachable''' adds another dimension to rule for conformance: +*If x is of an attached type, then y must be of an attached type. +This prevents us from circumventing attached status at run time. If x is of a detachable type, then y could be either a detachable or attached type. + +The same goes for routine calls. In a call: + + z.r (y) + +where x is the formal argument for r, then if x is of an attached type, then y must be of an attached type. + +===Stable attributes=== + +Stable attributes are really stable detachable attributes, as adding the concept of stability is meaningful only for detachable attributes. Declaring a detachable attribute as stable, means that it behaves like a detachable attribute except that its assignment rules mimic those of attached attributes. In other words, a stable attribute can never be the target of an assignment in which the source is Void or a detachable type. + + test: detachable TEST + note + options: stable + attribute + end + + +This means that even though stable attributes do not need to be initialized like attached attributes, once they are attached to an object, they can never be void again. + +===Rule for generic parameters=== + +Generic classes provide another question. A generic class like + +class + C [G] + ... + +allows us to create a type by providing a specific actual generic parameter for the formal parameter G. + +So, two valid derivations are: + + my_integer_derivation: C [INTEGER] + +and + + my_employee_derivation: C [EMPLOYEE] + + +If class C contains a declaration: + + x: G + +What do we know about the void-safety of x ? + +In the case of the INTEGER derivation above, we know x is safe because INTEGER is an expanded type. But often types like EMPLOYEE will be reference types which could be void at run time. + +So for a class like C [G] containing a declaration x: G : +* G is considered detachable and any class will work for an actual generic parameter +* Application of features to x must include verification of attachment (CAPs, attached syntax, etc) + +Constrained genericity can be used to create generic classes in which the generic parameter represents an attached type. If class C had been defined as: + +class C [G -> attached ANY] + ... + +then x in this class G represents an attached type. Consequently, the actual generic type in any derivation must be attached ... and feature calls on x are safe. + +===Rule for ARRAYs=== + +The rule for generic parameters applies to all generic types ... except ARRAYs. In the typical creation of an ARRAY, we would provide a minimum and maximum index. + + my_array: ARRAY [STRING] + + ... + + create my_array.make (1, 100) + +During creation, an area to store the appropriate number of entries is also created. And depending upon the actual generic parameter, these entries are either objects for expanded types or references for reference types. + +In the case of an actual generic parameter of an attached reference type, all the elements must be attached to instances of type during the creation of the ARRAY. The make procedure would not do this. Creation of an ARRAY in which the actual generic parameter is attached must be done using the make_filled creation procedure. + + create my_array.make_filled (1, 100, "") + +The third argument is an object of the actual generic type, in this case an empty STRING. Every entry in the newly created ARRAY will be initialized to reference this object. + + +