Re: [Caml-list] Execution time of class versus record

[Arnaud Spiwack <aspiwack@lix.polytechnique.fr>]

>> ...btw object coercion should never cost anything
>> since they are merely type level tools...
>>     
>
> Even in statically typed systems you might well want to shift work to run-time 
> (e.g. specialization of all-float records/arrays) so I see no reason to 
> expect coercion to be free.
>   
Well even in dynamically typed languages, a coercion should at runtime 
cost no more than a soundness check which is part of virtually any 
operation.

But well, I guess you mean that coercion could lead to a kind of object 
which is optimized in a certain way. Which I hadn't actually thought of, 
but this should be taken care of at compile time (if I remember well, 
the arrays of floats are actually compiled a different way, using 
different get/set primitive, there is still nothing at runtime). So in 
vew of this, the part of the coercion that'd be shift at run-time would 
be something rather rare (in the zoology of objects, object that deserve 
a specific run-time representation sound like a rather spare subset to 
me), an coincidental. Most coercion would still be no-ops.

Am I wrong ?
>   
>> At runtime, I can't see anything to preven objects to be exactly records
>> (with a bit of care taken during compilation for method names).
>>     
>
> How can the current representation of records handle virtual method dispatch?
>   
I'm not sure I will answer this question properly. But if we're talking 
of the same thing, virtual methods are not a runtime concern. You can't 
create object of a virtual class anyway. It's a mere typing issue (and 
this time for very real, this does not fiddle with any concrete 
representation of any sort).

I guess I haven't understand the question.
>   
>> John 
>> Skaller's answer is not really convincing either, since the type of a
>> value does not change the size of the value, having the same name
>> associated to different types does not seem to me a good motivation.
>>     
>
> I think this choice makes OCaml's object system more orthogonal to the rest of 
> the language.
>   
Which specific choice are you refering to right now? (you lost me 
somewhere on the track).
>   
>> Another lead is maybe something due to module compilation, the
>> earlier idea might imply that each module has it's own namespace (it's
>> the case for almost everything in OCaml, except, if I'm not mistaking,
>> method names
>>     
>
> and polymorphic variants.
>   
Indeed. For similar reason I reckon.
I wonder how polymorphic variants are handled at compile time. They 
probably get there label during linking I guess. I can't see how they'd 
work otherwise. (the OCaml manual states they are a pinch slower than 
non-polymorphic variants, could someone tell me what is the difference 
which makes that be?)
>   
>> If it is the motivation for having a runtime 
>> representation of objects different to that of records, the question
>> that raises nex is: what is the motivation for not having
>> module-specific namespaces for method names?
>>     
>
> If I have two modules containing two classes and I want them to be related, 
> how can you implement that with structurally-subtyped OO if method names are 
> local to modules?
>   
Well, you could still use #OtherModule.m to call the other module's "m" 
method. And using "open OtherModule" as well. I must confess I'm not so 
sure it really makes a lot of sense to have these like that, but at 
least it'd be rather consistent.
Anyway, since we raised the polymorphic variant point, it sounds 
unlikely that it'd be impossible to give non-colliding adresses to 
method names during linking, so this point is rather moot.


Arnaud Spiwack