Re: Adding setComment on SFieldMeta

Hello Franck

I am simply concerned that when you do toString on an Enum you do not see the type.  Just the name.  Leading to horrible bugs.  Why is this PROMPT different to that PROMPT?  I can see PROMPT in the table, but get("PROMPT") returns null?  etc.

I am also wondering if we really need getPrompt() instead of get(Prompt).  The latter is very Simplormish.

How about
1.  Declare and use the enum.
2.  For in builts give a special name, eg. "SPrompt" or S_PROMPT

Maybe change getUserProperties to getProperty(Enum property).  Would make it clearer.  But would be a pain for extendable enums.

Maybe make Descriptive a property later.

We can then argue about whether the key should be String or Object.  Won't really matter if "SPrompt" is used, so that it is clear.  Maybe make the actual Enum SPrompt, so that it can be statically imported.  

Put a fat comment on getPropety to say that enums are being used as name spaces.   Can one just have a type Enum?

Strings are simple.

Do what you think is best.

Anthony


At 08:08 PM 5/10/2009, you wrote:
>  
>
>Hi Anthony,
>
>> 
>> Hmm, I think you just made a good argument for not using the Enum!
>> 
>Well, I don't get you here...
>You seem to assume everybody expects that keys in Maps are String, and
>that no one will notice that SFieldProperty.PROMPT and "PROMPT" are not
>the same objects !
>
>I think on the contrary that using an enum object as the key for the
>library's own "user" properties makes it perfectly clear that they are
>internal to the library and will ensure that they won't conflict with
>the user namespaces (be they "clever" Strings or any other object).
>Moreover, users will use the setPrompt / getPrompt shortcuts, so they
>will probably never notice what the key is.
>
>> I suppose that different aps could use different enums, but the
>> potential for confusion is high.
>> 
>On the contrary, enums are the perfect namespaces for Maps. Using
>Strings with prefixes to try to mimic what enums do perfectly seems odd
>to me...
>
>What do you think I'm missing ?
>
>Regards,
>Franck
>
>


Spreadsheet Detective,
Southern Cross Software Queensland Pty Limited
54 Gerler Street
Bardon, Queensland 4065, Australia.

Email: [email protected]
www.SpreadsheetDetective.com
Ph: +61 427 830248 (Australian Eastern Standard Time)

"If the model seems correct only because the numbers look right, 
then why build the model in the first place?"


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/SimpleORM/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/SimpleORM/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/