W3C home > Mailing lists > Public > public-rdf-comments@w3.org > April 2013

Re: Futures

From: Gavin Carothers <gavin@carothers.name>
Date: Wed, 17 Apr 2013 15:10:51 -0700
Message-ID: <CAPqY83zS2U-+EdRPcLdSE6YZPcN=3rSrXYE-8TrQb0pi6RTSFw@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, public-rdf-comments <public-rdf-comments@w3.org>
On Wed, Apr 17, 2013 at 2:51 PM, Dave Longley <dlongley@digitalbazaar.com>wrote:

> 3. While WebIDL is a language for describing APIs meant to be implemented
> by browsers, we also expect the JSON-LD API (or something very close to it)
> to be implemented in various languages (eg: PHP, Ruby, Python). If we
> include Futures, these implementations would become more complex and their
> APIs may appear more foreign in certain environments. Implementors may
> avoid these undesirable effects and APIs will then deviate. I don't think
> this is necessarily that big of a deal, but it is an unintended consequence
> of making Futures first-class values in the browser ... as they won't be
> elsewhere.
>

The API for JSON-LD will not be the same in languages that are not mapped
by WebIDL. I would fully expect an async API in Python for example to vary
depending on if it was written using Twisted, libevent, or tulip. Callbacks
suck in every language, much work has been done in all of them to make that
work better. Heck in Java you won't even have function literals so good
luck with that. The API part is *really* only for Javascript, please don't
bring PHP, Ruby, and Python in. The algorithms will stay the same, the API
won't.

--Gavin
Received on Wednesday, 17 April 2013 22:11:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:32 UTC