[Swift-user] assigning file variables

[Michael Wilde]

I was envisioning approach (ii). I certainly dont want a file "cp" to 
take place, and I have not yet seen a need for (i), other than something 
related to retaining provenance across copies, which is not my need here.

I was envisioning (ii) more as a simple "reference" assignment, which 
made the target variable have the same state as the source variable, 
including the mapping.

Regardless, I dont think this is an issue we need to rush to resolve at 
the moment. Its more a matter of creating enough documentation and style 
examples so that people fall into paths that work for them.

My code is in transition but I put two version of it under: 
http://www.ci.uchicago.edu/~wilde/oops8.swift
http://www.ci.uchicago.edu/~wilde/oops8e.swift

oops8.swift doesnt work, but shows the structure of what I was trying to 
accomplish.

When I hit a few problems (like the extractint issue, file copy issue, 
mapping same file twice issue, and iterate condition issue) I created a 
simplified version oops8e.swift that used "echo" instead of the more 
complex app. oops8e now correctly does the nested 
foreach-iterate-foreach loops.

Next I'll be adapting the code to use structs to pass the large sets of 
files in and out of the app, so that the final functions arevery simple 
for the user to invoke. In doing this, I may need to go to ext mappers 
anyways, dont know yet.

It seems like the swift framework for this app is now working, and I'll 
post any new issues as they come up.

some notes, below...

On 2/25/09 9:32 AM, Ben Clifford wrote:
> The semantics of file assignments have been discussed on and of for some 
> years.
> 
> Those discussions have left two different ideas floating around in my 
> head:
> 
> i) = as copy
> 
>  The code file a <"foo">; file b<"bar">; a = b; behaves something like cp 
> bar foo.
> 
> Thats pretty straightforward, bu to implement and understandt unclear to 
> me if thats the right thing to do in many cases - for example, when 
> assigning into an array of files, you would end up with the members of the 
> array still being mapped to the filenames that the mapper associated with 
> the array gives, not the filenames of the rhs file in the assignment.
> 
> Its not clear to me if this behaviour, for example, would be useful in the 
> use case you specify. Why do you want to construct the filenames in a 
> difficult way? Is it because you want them to end up with that filename,

yes, in this case. I did try mapping the 2D array with simple_mapper, 
and that gave me names that were surprisingly acceptable, but not what I 
had planned. A simple variation on it might have worked though, 
something sprintf() like, which I could probably do with an equivalent 
ext mapper. So there is certainly a reasonable solution here.

> or because your application wants to generate them that way? In the 
> former, this model doesn't work, though in the latter, if you don't care 
> what they end up being called, thats fine.
> 
> ii) assignment-as-aliasing
> 
> file a; file b<"bar">; a= b turns a into an alias for b, mapped still to 
> the file "bar"; no copying takes place.
> 
> In your case, you'd then end up with an array of aliases to files that are 
> mapped by a bunch of single-file-mappers.

Yes, thats what I was looking for.

> I haven't really thought this second model through a huge amount but I 
> probably should sit down and play with it.
> 
> In your specific case, can you show the code that your trying to make 
> work? If you are running a foreachwhere the cardinality is known before 
> hand (i.e. you know how many iterations you want, before the start of the 
> loop) you can perhaps programatically construct a string[] array with your 
> constructed filenames, and then use an array mapper to use that array of 
> strings as the filenames for an array.

In this case I know the size of the inner array, the result of the inner 
foreach{} loop, at the start.  So that might work.
> 
> So one foreach loop to make string[] arraynames, then a statement to use 
> arraynames to map an entire array, and then your original foreach loop.

I can try that.
> 
> In the case of an iterate where the cardinality is not known before hand, 
> that method probably doesn't work.
>