On Friday 16 December 2005 22:25, Darren Duncan wrote: > At 10:07 PM -0800 12/16/05, chromatic wrote:
> >This is fairly well at odds with the principle that users shouldn't have > > to bear the burden of static typing if they don't want it. > This matter is unrelated to static typing. The state of whether a > variable is defined or not is orthoganal to its container type. I didn't say container typing. As I see it, your concern is what happens when trying to *coerce* something containing the undefined value. > But more to the point, if you assign your default values at strategic > places, you are not writing very much extra code at all. Objection: "not very much" extra code is asymptotically greater than no extra code. A change this great from Perl 5 seems like it ought to provide a whole heap of benefit to make up for the whole big heap of inconvenience everyone now has to live with. So far, I'm not even seeing a little heap of benefit. Mathematical-theoretic purity is a nice idea, but I'm usually too busy trying to do actual work to appreciate anything beyond "hey, can I write robust, maintainable working code without too much effort and time?" > Those few characters are nothing considering the amount of hassle > they can save. I didn't buy that argument from the "static manifest typing everywhere" folks either. What happens if you have a sparse array with the greatest index of 10 and you want to assign something with an index of 100? Do you have to give the array an explicit default value? What if you create it in a module somewhere? What if it's a generic array and you don't know when you create it what type of default value it should contain? What if 0 is a valid value that means something entirely different from "default initialized but unassigned"? All of a sudden, am I going to have to care about the default value of every container I create or receive from somewhere, just in case its notion of truth and definedness doesn't match mine? If so, how inconvenient is the code? If not, why not? -- c
