Many operations with MapFS require a full scan of the entire map every 
time, e.g. even asking for the files in a dir scans the entire map to 
filter it. So, if you need at least one reason not to, perf could be one!

On Thursday, August 7, 2025 at 7:08:13 PM UTC-7 Jason E. Aten wrote:

> I would just copy it into a separate file in your own project first--only
> to avoid confusing readers who would otherwise see the "testing" package
> used in production code.
>
> I mean, its such a simple thing that of course, sure, why not? :)
>
> type MapFS map[string]*MapFile
>
> // A MapFile describes a single file in a [MapFS].
> type MapFile struct {
> Data    []byte      // file content
> Mode    fs.FileMode // fs.FileInfo.Mode
> ModTime time.Time   // fs.FileInfo.ModTime
> Sys     any         // fs.FileInfo.Sys
> }
>
> On Thursday, August 7, 2025 at 12:38:03 PM UTC+1 Jeremy French wrote:
>
>> This is kind of a "should I" vs a "how do I" question.  
>>
>> Can anyone think of a reason not to use a MapFS in production code if you 
>> want an in-memory FS?  It's in the testing package, and clearly stated that 
>> its intended use is for testing.  Is it weird to use it for not-testing?  
>> Aside from the obvious caveats surrounding using an in-memory system in the 
>> first place.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit 
https://groups.google.com/d/msgid/golang-nuts/6994cd9e-8bb1-4e48-b0b2-3023b82beddbn%40googlegroups.com.

Reply via email to