[Developers] Perl API - just to make things confusing

[Tim Sturge]

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