Early std.crypto

[Jonathan M Davis]

On Wednesday, October 26, 2011 03:17 Steve Teale wrote:
> On Tue, 25 Oct 2011 23:45:58 -0700, Jonathan M Davis wrote:
> > On Wednesday, October 26, 2011 06:28:52 Steve Teale wrote:
> >> > An easy test is that if the interface takes a T[] as input, consider
> >> > a range instead. Ditto for output. If an interface takes a File as
> >> > input, it's a red flag that something is wrong.
> >> 
> >> I have a question about ranges that occurred to me when I was composing
> >> a MySQL result set into a random access range.
> >> 
> >> To do that I have to provide the save capability defined by
> >> 
> >> R r1;
> >> R r2 = r1.save;
> >> 
> >> Would it harm the use of ranges as elements of operation sequences if
> >> the type of the entity that got saved was not the same as the original
> >> range provider type. Something like:
> >> 
> >> R r1;
> >> S r2 = r1.save;
> >> r1.restore(r2);
> >> 
> >> For entities with a good deal of state, that implement a range, storing
> >> the whole state, and more significantly, restoring it, may be non-
> >> trivial, but saving and restoring the state of the range may be quite a
> >> lightweight affair.
> > 
> > It's likely to cause issues if the type returned by save differs from
> > the original type. From your description, it sounds like the range is
> > over something, and it's that something which you don't want to copy. If
> > that's the case, then the range just doesn't contain that data. Rather,
> > it's a view into the data, so saving it just save that view.
> 
> Well, yes Jonathan, that's just what I'm getting at. I want to save just
> those things that are pertinent to the range/view, not the whole panoply
> of the result set representation or whatever other object is providing
> the data that the range is a view of.
> 
> I could do it by saving an instance of the object representing the result
> set containing only the relevant data, but that would be misleading for
> the user, because it would not match the object it was cloned from in any
> respect other than representing a range.
> 
> Should not the requirement for the thing provided by save be only that it
> should provide the same view as that provided by the source range at the
> time of the save, and the same range 'interface'.
> 
> Is there an accepted term for the way ranges are defined, i.e. as an
> entity that satisfies some template evaluating roughly to a bool?

Ranges are defined per templates in std.range. isForwardRange, isInputRange, 
isRandomAccessRange, etc. And it looks like isForwardRange specifically checks 
that the return type of save is the same type as the range itself. I was 
thinking that it didn't necessarily require that but that you'd have definite 
issues having save return a different type, because it's generally assumed 
that it's the same type and code will reflect that. However, it looks like 
it's actually required.

What you should probably do is have the result set be an object holding the 
data but not be a range itself and then overload opSlice to give you a range 
over that data (as would be done with a container). Then the range isn't in a 
position where it's trying to own the data, and it's clear to the programmer 
where the data is stored.

- Jonathan M Davis