From: <rvj...@xs...> - 2007-04-14 11:26:51
|
I have a feeling that by overloading requirements on this we actually =20= came out with less than we started with. For me, the most useful =20 addition still would be to have optional type checking on method =20 arguments using a compact notation. As I initially stated, what =20 NetRexx does with parentheses and equal signs would be fine with me, =20 even if the =3D always gives newcomers a funny feeling. I understand =20 that a bit more verbosity and usage of USE ARG would be more in the =20 ooRexx tradition. I think changing this (back?) into IF via the need =20 for multiple constant expressions and the RAISing of different =20 conditions finally takes care of erasing almost everything what was =20 originally intended. What we need is a simple way to have *optional* type safety in method =20= arguments. What would be more to the point than having a single =20 convention (specifying the intended type of the argument right after =20 the argument)? What would be more to the point than having this raise =20= a single condition (an equivalent of 'you just committed a type error")? Doing this any other way will end us up with almost exactly what we =20 already could do in ooRexx, that is, doing a lot of work to check the =20= types of the arguments, making sure you are not forgetting any, =20 especially not when adding one. A simple mechanism would give you a better feeling about your code =20 because execution should not start when typing errors are committed. =20 If the condition that was raised on a type error includes a 'fallback =20= scenario' to look for methods with better signatures, you even could =20 provide method overloading. Not that I am terribly attached to that, =20 but I use it a lot on class constructors. Also, I believe type =20 checking is warranted, in my view for most cases when you work on a =20 system with multiple developers. As an aside, Ruby does not have method overloading. Ruby architect =20 Matz opposes method overloading when coupled with optional argument, =20 because the combination of type checking with optional arguments =20 leads to an combinatorial explosion. Without optionals, he might =20 consider to put it in. Also, I lost what the exact notation for it now is ... how do I check =20= the type of a method argument in the latest build? My previous test =20 does not work anymore. Ren=E9. On 13-apr-2007, at 22:44, Rick McGuire wrote: > Ok, I think I've come up with the perfect combination of keywords =20 > to implement this. I think everybody wants one that's short, so =20 > I'm going to choose IF. The condition expression will be =20 > terminated by the keyword THEN, and to cause a syntax error, you =20 > follow this with the keywords RAISE SYNTAX. > > So, the instruction > > ASSERT TRUE (a =3D b) SYNTAX 93 > > becomes > > IF a=3Db THEN RAISE SYNTAX 93 > > This is shorter than the other version, probably more readable, and =20= > gives Rony the ability to raise conditions as well as syntax =20 > errors. In other words, it's time to chalk the ASSERT instruction =20 > up as a bad idea and leave it out :-) > > Rick > |