Re: [imp-dev] A note on the different implementations of IValueFactory

[A.W.Lankamp@xxxxxx]

Like Jurgen said, the (de-)serialization stuff is factory independent, so
there are no 'portability' problems there.

As for the mixing of values from different factories; I assume most users
will stick to one factory implementation, so in the general case I don't
expect this to be a problem. For users that want to use different
factories together in one application, it may be necessary to provide the
ability to 'import' a value from one factory to another. This is pretty
easy to do; all we need is a function that re-constructs a given value
using a certain factory.

Cheers,
Arnold.

> Hi Bob,
>
> I wouldn't put a header on, because de-serialization gets a factory as
> a parameter.
> It's easy and safe to construct a value using one factory, and then
> serialize it and
> then de-serialize it using another. I wouldn't want to loose that
> looseness.
>
> I thought about a field in each value, but the overhead is way too
> big. Some (expensive) checks in each method of each factory would
> prevent problems too.
> Not a good idea either.
>
> I suspect that using some "double dispatching" tricks we could have
> each method in each value class degenerate to the reference
> implementation. This puts a larger implementation and maintenance
> burden on the factory implementations though...
>
> What's the run-time cost of a class annotation and checking it at
> run-time?
>
> Cheers,
>
> Jurgen
>
> On Tue, Jun 2, 2009 at 4:52 AM, Robert M. Fuhrer <rfuhrer@xxxxxxxxxxxxxx>
> wrote:
>> Thanks, Jurgen, for merging in the contributions, and THANKS!!! Arnold
>> for
>> the contributions!!! These are sorely needed improvements!
>>
>> As to the compatibility issue, how about putting some sort of a haeder
>> on
>> the serialization format to avoid the more subtle mix-and-match errors?
>>
>> On Jun 1, 2009, at 2:53 PM, Jurgen Vinju wrote:
>>
>>> Dear imps,
>>>
>>> I've merged the contributions of Arnold Lankamp (CQ 3288) to
>>> org.eclipse.imp.pdb.values. This includes the
>>> binary streamable (de)serialization format for values and two
>>> implementations of IValueFactory
>>> and respective implementations of IValue and friends.
>>>
>>> Note that values constructed from/by different IValueFactories are not
>>> to be mixed. We currently
>>> do not cater for this in any of the implementations. It wasn't one of
>>> our design decisions either to
>>> have such a feature (point to ponder).
>>>
>>> Caution advised! Mixing values from different factories is quite an
>>> easy pit to fall into.
>>> Common symptoms {sh,c,w}ould be:
>>>  - ClassCastExceptions
>>>  - surprising inequalities between values (also with the isEqual()
>>> method)
>>>  - surprising double occurring elements in sets or tuples in
>>> relations or keys in maps (caused by previous point)
>>>
>>> Nevertheless, the two new factories improve performance dramatically
>>> as compared to the reference implementation
>>> of IValueFactory. Pdb.fast is the current high speed champion in most
>>> of the tested analyses that deal with relations
>>> and pdb.shared wins for analyses that deal with trees a lot.
>>
>> --
>> Cheers,
>>  - Bob
>> -------------------------------------------------
>> Robert M. Fuhrer
>> Research Staff Member
>> Programming Technologies Dept.
>> IBM T.J. Watson Research Center
>>
>> IMP Project Lead (http://www.eclipse.org/imp)
>> X10: Productivity for High-Performance Parallel Programming
>> (http://x10.sf.net)
>>
>> _______________________________________________
>> imp-dev mailing list
>> imp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/imp-dev
>>
> _______________________________________________
> imp-dev mailing list
> imp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/imp-dev
>