[Swift-devel] [Bug 76] disable intermediate stageout of data

[Yong Zhao]

option 1) does not say it is of type string, but it is of type any, which
means it could be an opaque file that we are not interested in going into
the file content, in which case, a file name could be in place of the
content, it all depends on how the mapper interprete the value.

Yong.

On Thu, 5 Jul 2007, Ben Clifford wrote:

>
>
> On Thu, 5 Jul 2007, Yong Zhao wrote:
>
> > My original thinking about value/filename was that we don't distinguish
> > those at the logical level, essentially they could all just be values.
> > Then when we need to call mapper functions (getFilename, for instance), we
> > interprete the values differently. So in the case of getFilename, we can
> > interprete the value either as
> > 1) the filename itself, returning the value directly
>
> > 2) writing the value into a file, and returning an automatically generated
> > filename.
>
> > 3) some other possibilities, e.g. a directory of files.
>
> option 1 goes against the strongly typed model - if I have a brain image,
> I dont want an access to that brain image to suddenly be the string
> "brain.img" - that isn't of type 'braingimage', its of type 'string'.
>
> but the other two options work, I think - that's what a mapper does -
> expresses how swiftscript data is interpreted in various different ways
> - as a (set of) file(s), as a in-memory value, in some other form.
>
> But I don't think it will always be the case that each data object will be
> accessible in each form. For example, a brain scan doesn't make much sense
> being mapepd into the karajan runtime at the moment - we have nothing to
> do interesting things with such.
>
>  >
> > The current DSHandle interface does allow nested trees, so a mapper
> > could return a dshandle tree as the implementation currently stands.
> >
> > Yong.
> >
> >
> > On Thu, 5 Jul 2007, Ben Clifford wrote:
> >
> > >
> > > so I was thinking the other day while poking through code.
> > >
> > > 'data' in SwiftScript terms is mostly represented by DSHandle objects.
> > >
> > > such objects (which can have one of several implementing classes, and
> > > potentially more in future) have a number of properties, such as:
> > >
> > >  .  value - what the 'value' is, for adding to other values, using @strcat
> > > on, performing array/member access using [] and .
> > >
> > >  . submit-side location - what is extracted with @filename and used when
> > > that 'data' is passed to an application rather than being operated on by
> > > submit-side functions.
> > >
> > > Neither of these are compulsory (and I think in practice at the moment it
> > > works out that you either have a filename or a value and never
> > > meaningfully both).
> > >
> > > So a different model of mapping (which might work better when we want data
> > > that doesn't necessarily exist as discrete files or as in-memory values -
> > > the two examples that I've seen talked about are 'data from an sql
> > > database' and 'constants in a csv file') might be that mappers generate
> > > DSHandle trees (specifically a mapper generates a DSHandle, which might
> > > have descendants). Those DSHandles might have values, might have
> > > filenames, might have other attributes, might have ongoing annotation
> > > (which could include keeping track of where within-this-run copies have
> > > been made).
> > >
> > > --
> > > _______________________________________________
> > > Swift-devel mailing list
> > > Swift-devel at ci.uchicago.edu
> > > http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel
> > >
> >
> >
>