flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: [Proposal] Add PostCodeValidator and PostCodeFormatter to the SDK
Date Sat, 10 Mar 2012 09:59:33 GMT

On 10/03/2012 12:22, Justin Mclean wrote:
>> 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.
Well the conversion game from boolean to number is best *read* like this:

        var wrongNess: Number = 0.0; // I wouldn't use "count" as it 
doesn't mean anything, wrongFactor might be something...
        if( invalidFormat ) {
            wrongNess = 1.0;
        if( invalidChar ) {
            wrongNess += 1.0
        if( wrongLength ) {
           wrongNess += 1.5:

>> 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.

Then we should write a consistent shape on a wiki page. (see other 
mailinglist entry about code convention in wiki)

>> 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.

I am not of the believe that putting code in function increases 
readability. Stepping through with the debugger However: private static 
functions are the least evil.
That being said: programming for possibilities is usually a really bad 
idea. I think it can be implemented again when its time has come. By 
then the structure of the code may already
be entirely different.

> 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.

Its not about a "standard" its about a definition: What does the 
documentation of the tool say? Does it say: "It can verify any code" "It 
can verify some code" "It can very special code" "It verifes ITU 
standardized", .... etc. I wasn't sure about this, that's all.

> 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. 

Actually double width characters can be typed in accidentally easily. If 
you hit a wrong key on the keyboard then you suddenly type in 
full-width. I think most japanese people are used
to check for single width but it depends on the font and the  eye-sight 
to spot the differences. The real problem is that that they do use them 
in office documents (where they usually write addresses -> copy paste).
However: This "validator" usually sits in front of a server-side 
validation - right? Some server-side validation accepts full width, some 
doesn't. It should optional. How about using
the character "N" instead of "N" to check for double width numbers 
(only!) and "A" instead of "A" to check for double-width characters. 
All this stuff sounds already a lot like reg-exp.

>> 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.

Typo on my part: I will *note* a refactoring of the current signatures :)

>> 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.

I have never had that problem without the "@private" statement but I 
admit that I started from a late version of flex to use asdoc.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message