+1
I think you make a good point. It's no extra effort to append the data
type to the name. If annotations is to become a wild west then
assuming everything is a string unless proven otherwise is a little
rediculas. It might be better to take it one step further since above
you usefloat when
On Sun, Jun 6, 2010 at 12:36 AM, Mark Plotnick mark.plotn...@gmail.comwrote:
I'm not sure we ought to devote bytes in the rather limited length
annotations for data type names. Maybe have an optional (URL to a)
schema that describes what the restrictions are.
If the schema specified in the
Never mind, I misinterpreted what the problem being solved was
I'm not sure we ought to devote bytes in the rather limited length
annotations for data type names. Maybe have an optional (URL to a)
schema that describes what the restrictions are.
On Sun, Jun 6, 2010 at 12:23 AM, Mark Plotnick mark.plotn...@gmail.comwrote:
If you use JSON, the types should be visible after you unmarshall the data.
Visible, yes. Checked, no.
Every client would have to check the type before using the value.
--
Harshad RJ
http://hrj.wikidot.com
-1
Since the underscore is an acceptable char to variable/attribute
names, you would surely end up with unwanted type coercions... if a
developer chose _int for the last part of the attribute, it would
force coercion to integer... which you cannot be sure it's what he/she
wanted in the first
Hi Andre,
I understand your concern. I was trying to propose one possible way of doing
things. I welcome other suggestions as well, but each will have its own
merits / demerits.
We first need to see if the concept of a data-type is really a concern. I
think it is a nice-to-have feature, as it
On Fri, Jun 4, 2010 at 9:41 AM, Harshad RJ harshad...@gmail.com wrote:
Suggestions for data-types:
int : Integer
float : Floating point number
url : A well formed URL
To add to this list of data-types:
str: To force to a string
Say, you have an attribute whose label ends with _int. So to
