1. Idea for 'documenting' unused values
- Posted by Derek Parnell <ddparnell at bigpond.com> Jul 20, 2004
- 515 views
Any thoughts about this idea...? I created an include file (ign.e) that contains ... without warning global procedure ignore(object x) end procedure with warning then use it like this ... include ign.e function Foo(integer a, integer b) ignore(a) ignore(b) return 0 end function ignore(Foo(12,2)) In other words, whenever you want to tell people who read your code, that you are deliberately ignoring a value (eg. a parameter or function return), you just wrap it inside 'ignore()'. I *know* it adds the overhead of a useless call, but maybe that's worth it in the long run. It would be nice if this functionality was built-in to the language/interpreter. -- Derek Parnell Melbourne, Australia
2. Re: Idea for 'documenting' unused values
- Posted by cklester <cklester at yahoo.com> Jul 20, 2004
- 510 views
Derek Parnell wrote: > > In other words, whenever you want to tell people who read your code, that > you are deliberately ignoring a value (eg. a parameter or function return), > you just wrap it inside 'ignore()'. The "old way" is faster and just as clean (if not cleaner, just by saving keystrokes and the overhead of one or more function calls). VOID = Foo(12,2) Even IGNORE = Foo(12,2) is one keystroke and two function calls less than the proposed ignore(). Maybe you could provide a good example that would clearly show a distinct benefit of ignore(). -=ck "Programming in a state of EUPHORIA."
3. Re: Idea for 'documenting' unused values
- Posted by Derek Parnell <ddparnell at bigpond.com> Jul 20, 2004
- 493 views
cklester wrote: > > Derek Parnell wrote: > > > > In other words, whenever you want to tell people who read your code, that > > you are deliberately ignoring a value (eg. a parameter or function return), > > you just wrap it inside 'ignore()'. > > The "old way" is faster and just as clean (if not cleaner, just by > saving keystrokes and the overhead of one or more function calls). > > VOID = Foo(12,2) > > Even IGNORE = Foo(12,2) is one keystroke and two function calls > less than the proposed ignore(). > > Maybe you could provide a good example that would clearly show a > distinct benefit of ignore(). I was trying to create a single approach to handle TWO different situations. One is when you want to ignore a function return value. And the other is when you want to ignore passed parameters. Currently we use two or more different ways to handle these situations. For ignoring function returns, the common methods are ... x = func( . . . ) where 'x' is commonly called VOID or junk or whatever... Another method is ... if func( .. . .) then end if But that only works for atomic return values. For ignoring parameters we have our good friend 'without warning'. The problems with this is that it can accidently hide warnings we *are* concerned about (because we forget to turn warnings back on). It also turns off other warning messages that having nothing to do with unused parameters -- such as unused local constants, or functions without any return value, etc... My approach, with ignore(), handles both situations and is very specific about what we are doing and with what we are doing it to. How many people have ways around all those warnings that are generated by using Win32lib event handlers? global procedure Click_Button(integer self, integer event, sequence parms) Most of these handlers never use 'self' or 'event' and only sometimes use 'parms'. -- Derek Parnell Melbourne, Australia
4. Re: Idea for 'documenting' unused values
- Posted by "Mike Nelson" <MichaelANelson at worldnet.att.net> Jul 20, 2004
- 472 views
> How many people have ways around all those warnings that are generated > by using Win32lib event handlers? > > global procedure Click_Button(integer self, integer event, sequence parms) > > Most of these handlers never use 'self' or 'event' and only sometimes > use 'parms'. I use VOID for this situation as well: global procedure Click_Button(integer self, integer event,sequence parms) VOID=self VOID=event
5. Re: Idea for 'documenting' unused values
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jul 20, 2004
- 478 views
On Tue, 20 Jul 2004 06:25:21 -0700, Derek Parnell <guest at RapidEuphoria.com> wrote: >Any thoughts about this idea...? Probably the best solution given the tools available. I will offer void() or used() as alternative shorter names for the procedure, not that I'll worry if the consensus goes against me. There is one other thing I feel the need to mention, which is object(); an utterly, utterly useless routine which exists only for completeness, and, if Rob felt so inclined, could do this job with no overhead whatsoever. Of course it requires an interpreter (etc) change, so that "object(x)" does not complain "function result must be used or assigned". I'm not entirely sold on that, "don't "object" if (x) is unused", but at least it offers no unnecessary pollution of the namespace... Actually, there may also be a third use: completely unused (and unassigned) variables. Just occasionally, I've defined the data I know I *will* need, but am testing before it ever gets used, and I don't actually want a dummy init, because it may block an error path. It is pretty damn rare though, since {} or 0 would be ok 99.9% of the time. Just so you understand: object(x) [with *zero* overhead] kills the warning message; y=x or somesuch would crash at runtime. Nothing you could do for that with the current tools anyway. Can I remind you all that I did state that it is *very* rare, and no, I don't have an example Bad programming practice to boot. Aside from all that, in the long term (in posetf) I plan to use #()=, since that marries in with multiple assignment handling, and avoids the overhead mentioned; obviously not [yet] available in Euphoria. Whew, so much for a quick reply while my tea brews (stews), Pete
6. Re: Idea for 'documenting' unused values
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jul 20, 2004
- 500 views
On Tue, 20 Jul 2004 07:05:54 -0700, Derek Parnell <guest at RapidEuphoria.com> wrote: >Another method is ... > > if func( .. . .) then end if > >But that only works for atomic return values. > <reshuffle> >How many people have ways around all those warnings that are generated >by using Win32lib event handlers? I've even used "if sequence({x,y,z}) then end if" before now... And countless instances of: if integer(self) or integer(event) or sequence(params) then end if vs: ignore({self,event,params}) Much better, but would prefer an inline syntax for unused params... (Any ideas?) >For ignoring parameters we have our good friend 'without warning'. The >problems with this is that it can accidently hide warnings we *are* >concerned about Ugh, bad memories: Early experience on my first job: warnings flashing by ten a penny; guess what, first bug I spent *ages* fixing? The compiler had already warned me and everyone else about, zillions of times. The dipshit I was working for, who had already spent longer than should have been allowed looking for that bug and frankly (if he hasn't been sacked or more likely long since retired by now) would still be looking for to this day, ended up accusing me of breaking the system ... because (and I think you all know what I'm about to say) the warning messages were "wrong" when he recompiled... <shudder> Pete
7. Re: Idea for 'documenting' unused values
- Posted by "Mike Nelson" <MichaelANelson at worldnet.att.net> Jul 23, 2004
- 496 views
Derek's idea of an ignore() procedure is excellent in terms of being self-documenting. If it were implemented in the interpreter, the overhead of the procedure call could be optimized away, just as is done for then platform() function. -- Mike Nelson
8. Re: Idea for 'documenting' unused values
- Posted by irv mullins <irvm at ellijay.com> Jul 23, 2004
- 511 views
Mike Nelson wrote: > > Derek's idea of an ignore() procedure is excellent in terms of being > self-documenting. If it were implemented in the interpreter, the overhead of > the procedure call could be optimized away, just as is done for then > platform() function. Perhaps I misunderstand the problem, but isn't this about unused parameters (which must nevertheless be included as placeholders) causing warnings? If that is the case, then Euphoria should provide a dummy type to be used as a placeholder, one which wouldn't generate the warning. Should be easy to implement. Irv
9. Re: Idea for 'documenting' unused values
- Posted by Derek Parnell <ddparnell at bigpond.com> Jul 24, 2004
- 497 views
irv mullins wrote: > > Mike Nelson wrote: > > > > Derek's idea of an ignore() procedure is excellent in terms of being > > self-documenting. If it were implemented in the interpreter, the overhead of > > the procedure call could be optimized away, just as is done for then > > platform() function. > > Perhaps I misunderstand the problem, but isn't this about unused parameters > (which must nevertheless be included as placeholders) causing warnings? No. It is *also* about unused function return values, not just unused parameters. > If that is the case, then Euphoria should provide a dummy type to be used > as a placeholder, one which wouldn't generate the warning. Should be > easy to implement. I guess you mean something like ... procedure Click_Button(integer self, ignore, ignore) . . . end procedure This is a nice idea too. We could expand it to something similar for function returns... void = FuncA() -- Derek Parnell Melbourne, Australia
10. Re: Idea for 'documenting' unused values
- Posted by "Juergen Luethje" <j.lue at gmx.de> Jul 24, 2004
- 487 views
Derek Parnell wrote: > irv mullins wrote: >> >> Mike Nelson wrote: >>> >>> Derek's idea of an ignore() procedure is excellent in terms of being >>> self-documenting. If it were implemented in the interpreter, the overhead of >>> the procedure call could be optimized away, just as is done for then >>> platform() function. >> >> Perhaps I misunderstand the problem, but isn't this about unused parameters >> (which must nevertheless be included as placeholders) causing warnings? > > No. It is *also* about unused function return values, not just unused > parameters. > >> If that is the case, then Euphoria should provide a dummy type to be used >> as a placeholder, one which wouldn't generate the warning. Should be >> easy to implement. > > I guess you mean something like ... > > procedure Click_Button(integer self, ignore, ignore) > . . . > end procedure > > > This is a nice idea too. Agreed, very nice and straightforward. To make this even more self-documenting, I think I would prefer something like this: procedure Click_Button(integer self, ignore event, ignore parms) . . . end procedure I believe this would also require less changes in the Euphoria parser. > We could expand it to something similar for > function returns... > > void = FuncA() Maybe the same reserved word could be used to serve this purpose? ignore = FuncA() For me as a layman, it looks as if changes in the Euphoria syntax like these are rather easy to implement. Maybe we can see them already in Eu 2.5? Regards, Juergen
11. Re: Idea for 'documenting' unused values
- Posted by Derek Parnell <ddparnell at bigpond.com> Jul 24, 2004
- 477 views
Juergen Luethje wrote: [snip] > Agreed, very nice and straightforward. To make this even more > self-documenting, I think I would prefer something like this: > > procedure Click_Button(integer self, ignore event, ignore parms) > . . . > end procedure > > I believe this would also require less changes in the Euphoria parser. > > Maybe the same reserved word could be used to serve this purpose? > > ignore = FuncA() > Juergen, I think you have got it right. This is the best solution I've seen so far. -- Derek Parnell Melbourne, Australia
12. Re: Idea for 'documenting' unused values
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jul 25, 2004
- 521 views
On Sat, 24 Jul 2004 10:18:59 +0200, Juergen Luethje <j.lue at gmx.de> wrote: >I think I would prefer something like this: > >procedure Click_Button(integer self, ignore event, ignore parms) I would prefer: procedure Click_Button(integer self, integer, sequence) ie, if a type is followed immediately by , or ) in the parameter list then by not specifying any name it is pretty clear you are not going to reference the parameter. If block comments are allowed, then procedure Click_B(integer self, object /*event*/, object /*parms*/) not only documents what the missing parameters are (should you feel the need) but also by using object you avoid a tiny bit of type checking overhead. Without block comments you could code: procedure Click_B(integer self, object, --event object) --parms Regards, Pete