Lutger wrote:
Denis Koroskin wrote:

On Sat, 17 Oct 2009 00:54:51 +0400, Denis Koroskin <2kor...@gmail.com>
wrote:

On Sat, 17 Oct 2009 00:28:55 +0400, Denis Koroskin <2kor...@gmail.com>
wrote:

On Sat, 17 Oct 2009 00:22:54 +0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:

Jason House wrote:
if fun or gun is impure, then they should not be callable by the
contracts. Because of that, order is irrelevant.
1. Restricting calls to pure functions is sensible, but was deemed too
restrictive.

2. Even so, there's difficulty on what to cache. The amount cached may
depend on both the old and new object (in my example it only depends
on the old object).

3. There's too much hidden work and too much smarts involved. I just
don't think that's a feasible solution with what we know and have
right now.


Andrei
When not just let users one variable of type Variant per contract to
store whatever they want?
I mean, not a Variant, but a Dynamic* object so that the following would
be possible:

void push(T)(T val)
in(storage)
{
     storage.oldSize = this.size; // store
     //storage.anyDynamicProperty = anyDynamicValue; in general case
}
out(storage)
{
     assert(storage.oldSize + 1 == this.size); // access
}
body
{
     // impl
}

*do you recall the Dynamic class discussion (a class that allows any
arbitrary methods and properties access, similar to JavaScript objects
or dynamic objects in C#)
On second thought Dynamic objects need run-time reflection that D
currently lacks.

Alternatively users may be given a Variant[string] assoc.array as a
poor-man's replacement for a full-fledged Dynamic object:

void push(T)(T val)
in(storage)
{
     storage["oldSize"] = this.size();
}
out(storage)
{
     assert(*storage["oldSize"].peek!(int) == this.size - 1);
}
body
{
     // impl
}

The contracts userdata would be stored in a stack alongside with monitor,
classinfo etc for classes, and past the data fields for structs.

What is the benefit of variants here? Maybe I'm missing something, it just seems a little verbose and lose out on the type system (IDE support and such). Wouldn't it also tie the variant type to the language or is that not a problem?

The nice thing there is that you have a single type to be a generic bag for any types.

Andrei

Reply via email to