Well.. God.. Sorry all for starting this. :) Use what you want. I'll keep it on cause I'm used to that type of environment. Used to declaring variables. And it's in my head.
On 5/10/09 1:09 AM, "Joe Lewis Wilkins" <[email protected]> wrote: > Following this thread has pushed another one of my buttons and I > cannot resist getting on my soap-box and inserting my two-bits. > > We have "all" become accustomed to protecting ourselves from > ourselves. To the point where some of us pass laws requiring that > everyone protect themselves. I'm talking about INSURANCE. The best > "insurance" against having anything happen is an alert and active > mind. Insurance merely puts us to sleep; allowing us to be less than > vigilant and knowledgeable within all aspects of our lives. Not > declaring vars merely promotes sloppiness and, eventually, stupidity. > The President is going to spend enormous sums of money promoting > Health Insurance, when the best insurance is almost free; preventive > medicine which we have neglected for decades. We just need to be > diligent about all things. Education, eduction, education!!!!!!!! > > Joe Wilkins > > On May 9, 2009, at 8:47 PM, Mark Wieder wrote: > >> Jacque- >> >> Saturday, May 9, 2009, 6:01:53 PM, you wrote: >> >> Ah... I *knew* this would push Jacque's buttons... <g> >> >>> 1. The main strength of xtalk is that you do not have to declare or >>> type >>> variables. Sticking them up there at the top of every handler removes >>> one of the main advantages of using Rev in the first place. >> >> I seriously take issue with that being "the main strength" of xtalk. >> >>> 5. And finally, what's wrong with being lazy? :) The smart programmer >>> finds the easiest way to do things. That's what Rev is all about. >> >> Laziness is one of the big reasons I *do* declare my variables. If the >> compiler is smart enough to catch all kinds of errors for me, why >> should I go through all the debugging work at runtime? I believe in >> letting the computer do the hard work for me, otherwise I might as >> well just be coding the cpu's opcodes by hand. >> >>> None of these things is outweighed for me by the fact that >>> explicitVars >>> might catch a few typos. The engine catches most of those anyway and >>> throws an error. >> >>> Back to today's response: >> >>> The debugger pinpoints the exact source of the misspelling if it >>> happens; how hard is that? I'm a pretty good typist though, so I >>> don't >>> get caught out too often. I suppose if you are really as bad a >>> typist as >>> your theoretical example, then yes, you'd want some help. ;) >> >> <puts on a SNL snarl> >> ...Jacque, you ignorant slut... >> <returns to reality> >> You're missing the point. The purpose of explicitVars is to catch >> things that slip by the compiler otherwise. If it's just a simple >> misspelling of a keyword the compiler will catch it anyway, as you >> pointed out. But explicitVars will let you know if you've mistyped a >> variable name when the "friendly" compiler would helpfully generate a >> new variable instead of using the one you intended. And it will help >> when your fingers forget to place a space after "the" and instead of >> the variableNames ending up in a variable you end up with empty. >> >>> I once took over a project from someone who used explicit >>> variables. I >>> stripped out all the declarations so I could read the scripts >>> comfortably. The stack size was cut in half (!). No lie. There were >>> all >>> kinds of handlers in there with something like 8 lines of >>> declarations >>> and three lines of actual script. Waste of time and space. >> >> I recognize hyperbole when I see it, but nonetheless I don't think you >> can have 8 lines of declarations and three lines of actual script (and >> of course someone will post some code that proves me wrong). If you >> come across a handler like this then you have at least five lines of >> declarations that are not being used. And then you're absolutely right >> to strip them out <g>. >> >> -- >> -Mark Wieder >> [email protected] > > _______________________________________________ > use-revolution mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
