[Developers] Perl API - just to make things confusing

[Michael Jones]

Hi TIm, the only time I'm talking about implementing such a conversion
is if the submitted type does not match the expected type, otherwise
take it at face value.  I think that eliminates most of the times it
would be an inconvenience for anyone.

Adding the "warnings" property, which indicates when this is invoked,
takes care of the rest, IMO.

In any case, this is a flaw in the JSOn

On 8/24/07, Tim Sturge <tsturge at metaweb.com> wrote:
> Michael Jones wrote:
> > Hi Tim,
> >
> > On 8/24/07, Tim Sturge <tsturge at metaweb.com> wrote:
> >
> >> Firstly thanks to everyone (Kirrily, Michael, Hayden) for working on this.
> >>
> >> I'm aware of the issue that some dynamic languages (python) distinguish
> >> quite strongly between string, int and float, some (javascript) between
> >> string and number and others (perl, PHP) don't really distinguish any of
> >> them. (The question mostly boils down to whether "55"+"11" is "5511" or 66).
> >>
> >> JSON distinguishes between string and number (as it is built on
> >> Javascript) and MQL distinguishes floats from integers (although it does
> >> automatically promote integers to floats when necessary). JSON and MQL
> >> also distinguish the boolean true as distinct from the integer 1 and the
> >> boolean false as distinct from the integer 0
> >>
> >> I'm wondering how much difficultly that will cause in Perl and PHP (not
> >> languages I have interfaced MQL to myself, but languages that we at
> >> Metaweb are 100% committed to working well with Freebase). So please let
> >> me know how this ends up working; I don't want MQL to impose unnecessary
> >> barriers to Perl (or PHP) users and if we need a "perl mode" then I
> >> would be willing to consider what its requirements would be.
> >>
> >
> > In general, it would be useful if Metaweb would cast sumitted values
> > to their appropriate type, where possible.  You already mentioned how
> > you "promote" integers to float, where approriate.  Similarly, MW
> > converts strings to datetime, when that's expected.  This same
> > approach could be taken with strings, where if a property expects a
> > string type, it would interpret a submitted number as an ascii string,
> > rather than dying.  A nice touch would be if queries generated
> > warnings, as well as error messages, which could be a property of
> > successful response objects, and which would contain messages like
> > "Warning: Converted integer 2007 to the expected ascii string '2007'
> > in property "name" of query 'yearbook_write'."
> >
> > I think a general approach like the above is consistant and much
> > better than an exceptions based approach, like the "Perl mode" hinted
> > at.
> >
> I agree with the implicit conversion implementation, but I think it
> really does matter which language you are using on the back end.
>
> In Perl, you would expect me to convert 0 to "0" or false depending on
> the position, but not false to "false" (because you never generate false
> to begin with, and why would you stringify it anyway?).
>
> On the other hand in Python, if you give me 0 which I convert to "0" and
> give you back "0" in the result, you will die with a TypeError when you
> increment it as they are really not the same.  Here, your code needed to
> know that you had the wrong thing to begin with, not at result time.
>
> There are some ugly cases as well; one that came up recently was that
> 1971 might well be converted to "1971" as a year (datetime) but 23 then
> converts to "23" (11pm in hours) rather than "0023" (year 23 when the
> Romans were doing something we were interested in). Having the strict
> rules (4 digits in quotes) helped uncover a bug in the client
> application that otherwise would have been hidden.
>
> My point with "perl mode" is that this feature is clear winner for Perl
> and PHP users, but equally a clear loser for Javascript and Python
> users. So I'd be happy to provide it as an option, but that's different
> from buying into the philosophy that it is fundamentally the correct
> thing to do all the time. Different languages have made different
> choices and the default for MQL should be the correct behaviour default
> for Javascript rather than any other language.
>
> How does that sound? What would the least inconvenient switch be? (I'm
> thinking about a parameter in the envelope at the same level as the
> "query" keyword.)
>
> Tim
>
>
>
>
>


-- 
____________________________________________________________________

 Michael Jones, Gamer at Large
szaijan at ternea.com
____________________________________________________________________