Re: Stats v2 proposal - for Thursday's meeting

On 12/12/2012 12:43 AM, Martin Thomson wrote:
> On 11 December 2012 15:26, Harald Alvestrand <harald@alvestrand.no> wrote:
>> Each new interface class requires the addition of approx. 3 files to Webkit
>> (IDL, .h and .cc) (at minimum), and causes the generation of half a dozen
>> more, resulting in a significant number of added code bytes.
>> If the type should be carried all the way through WebKit to the underlying
>> browser, it usually takes about 6 more files to accomplish that.
>>
>> It's an uncomfortable meeting place between a strongly typed language and a
>> proto-typed one.
> I feel your pain, but I don't feel especially motivated to take on any
> more work.  Unless the code for the strongly typed portion is required
> to directly provide the interfaces that the application JavaScript
> uses, it's fairly trivial to make a JavaScript shim that constructs
> the necessary objects.  Throw JSON strings across the wall.
> Inelegant, but perfectly functional.
Yup. I was thinking this morning while walking to work on how such a 
translation layer could be made.
There is always ugliness (for instance, when you turn dictionaries into 
JS objects, you make the implicit statement that you'll never use the 
"prototype" attribute), but nothing exceptionally ugly.

One logistical problem is that we have to have a spec that specifies the 
implemented interfaces (WebKit also has a policy that it doesn't accept 
API changes that aren't at least in a draft spec), and there isn't a way 
(AFAIK) to check a Javascript conversion layer into WebKit.
But we could expose it in the spec.

(Having used databases designed both before and after the Relational 
Revolution, I'm somewhat skeptical of the idea that hierarchies, 
pointers and containment are always Good Things.  But that, as much 
else, is a matter for debate.)

>
> As I've already said to someone on my team here today, who wanted to
> use avoid the overhead of making a new module to do a new thing:
> trying to limit the amount that a programmer has to type is an
> admirable process goal, but never let it compromise the integrity of
> your architecture.
>
> --Martin

Received on Wednesday, 12 December 2012 11:00:22 UTC