Hi, > Couldn't you just use var invalidFormat: Number = 0 or 1 ? I could but then I would be casting a Number to boolean on the other fields.
>>> *) You mix "brace in new line" (left) with "brace in current line" (right), >>> afaik its in the current line. > PostCodeValidator - 499 & 513 just as one example Think I've fixed them all. When some work is done of the Flex formatter I'll run the code through that. > Personally I see bad sides in the one with the missing else ... however: > again: What did the Flex Gui The SDK code is inconsistent in this case and uses both forms. > I made the experience that programming for possibilities is a very bad idea. > I am not necessarily talking about the performance (which it also affects) but > also the readability. I think the readability is fine and it has been improved in the latest checked in version. > The question is how this util is defined Personally it more how people want to use it, standards are only as good as how much they are used eg country code should in some cases be used in postcodes but is generally ignored. I've added support and test cases for it. > This is a big problem for all number validation in japan. Oh: They also have > double width A-Z ＡＢＣ．．．ＸＹＺ: try to build a search engine around that! May need to support that down the track if any country postcodes contain alpha characters and use wide characters. Currently I'm not aware of any. > I see thanks! And thinking about it further: shouldn't the "result" have a > error-weight? To be compared with other errors? It could be. By default only the first error is shown to the user when validating forms and the like. Also none of the other validators do that. > I do not see a need for this to be consistent, does it? Anyways: I will not a > refactoring of this signature for Flex X somewhere. I think it does need to be consistent with the current validators. Forms will often use a variety of validators and often place them into a single array so the entire form can be validated in one go. Having them all work and look the same makes them easier to use. > I attached three examples how it think it could work else. All have less > dependencies and better performance. Better performance is not really an issue here - how fast do you need to validate a post code as a use types? > Then my question would be: Why is it private? It's not private it's public the "@private" comment is for the documentation so it handles setters and getters correctly. Thanks, Justin
