http://d.puremagic.com/issues/show_bug.cgi?id=7515
--- Comment #3 from Jonathan M Davis <jmdavisp...@gmx.com> 2012-03-06 15:27:13 PST --- > 1) If they don't already say it, then I suggest to add in the ddoc of the > functions that the translation arrays have a length 128. This for both old D > programmers and Python programmers. I don't know. It seems to me that that's an implementation detail. makeTrans doesn't even return a static array. It returns a dynamic one. So, as long as the array passed to translate comes from makeTrans (as it should), it's complete non-issue. If anything, I'd argue for creating a struct (e.g. TransTable) which just held the dynamic array without giving access to it so that no one _can_ screw with it (since screwing with it is just going to break code). It seems to me that the only reason that makeTrans exists in the first place rather than just putting it in translate is so that you can reuse the translation table. No one should be messing with it or passing anything else to that version of translate. So, why does the length of the array matter to the user of makeTrans or translate? And actually, I'm _really_ tempted to just go and change it so that it returns a struct which you can't mess with and is only created by makeTrans. That completely resolves any possible issues caused by someone passing the wrong array to translate. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
