generated file has mixed up namespaces

[dallinbeutler]

here is the repo with the issue.
while working through the aardvark.media tutorials starting with the template, I created two different model files. ModVector.fs has a Components namespace with two modules each containing DomainType records.

The files that get generated each have problems ( which I added comments to for clarity)
Another issue is that ModVector.g.fs doesn't get added to the project automatcally like Model.g.fs does. (Worth noting that it would have to be added above Model.g.fs because of dependencies)

[dallinbeutler]

Just notice that the template uses v4.2.4 instead of the latest v4.3.0.. I guess this could just be a template out of date issue.

[dallinbeutler]

Tried updating the template packages, but paket can't seem to resolve anything higher than what it currently is. (some sort of dependency resolution hell?)

[krauthaufen]

hey, we recently upgraded everything to fsharp.core 4.6.2 and just forgot to upgrade the template too.

The .g.fs files are not added to the project, they're "magically" smuggled in by the MSBuild plugin which works fine for VS2017/19 but always had some problems in vs code. (you can always add it to the project manually) The DomainType-Attribute instructs The plugin to generate the incrementalized version for the type and therefore you need it whenever using it in your model.

[dallinbeutler]

ahh, so the template including model.g.fs by default was just to show how it works/ compatibility with VS code?
So the impression from the generated code that every record type used in a larger record also needs the DomainType-Attribute to properly work? otherwise it would be an immutable swap on that whole piece.
So should I close this and create an issue over at the template repo to get updated? I assume that will fix the issue mentioned above

[haraldsteinlechner]

i just updated template but could not yet check your problem unfortunately.

[dallinbeutler]

Thanks for doing that! I just tested it. Looks like its a different flavor of the exact same issue. here is the updated repo. Looks like it's now just adding "Mutable." to the front of every static call to create or update. Removing it would be the correct way to call.

[haraldsteinlechner]

oh. i will look into this tomorrow Dallin Beutler <[email protected]> schrieb am Do., 8. Aug. 2019, 21:49:

…

Thanks for doing that! I just tested it. Looks like its a different flavor of the exact same issue. here is the updated repo <https://github.com/dallinbeutler/UpdatedAardvarkDomainIssue>. Looks like it's now just adding "Mutable." to the front of every static call to create or update. Removing it would be the correct way call. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AAD5KAOSVGSLWF5IMUGRJODQDR2DPA5CNFSM4IKBU3DKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD34WXFA#issuecomment-519662484>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD5KAL6ZTUN2UUI6JMK7VTQDR2DPANCNFSM4IKBU3DA> .

[haraldsteinlechner]

yep, there seems to be problems with modules in model files. we typically put models into namespaces. So as you can see in media examples we follow the pattern: Model.fs, App.fs. App provides the module App which also holds the functions.
you might have something similar to this, right?
haraldsteinlechner/UpdatedAardvarkDomainIssue@1f811e2

at the moment the compiler works like this in this regard:

• if we have a module in the Model file, take it's declaration. What happens is that we get duplicate definition of the module.
• otherwise, take the namespace and put stuff into an autoopen module Mutable

should we fix it or stay as is, document and only support namespaces? @krauthaufen

[dallinbeutler]

ahh, an interesting alternative to laying things out than I'm used to. thanks for that example. Yeah, same issue, and the changes you made would fix it. I only ever really work with modules, so it's a mindset change
Are there advantages to using this namespace layout over putting Model, msg, and update (and view, if the type provider got up and running) in one module?
Or that's just the way of working around issues you guys encountered while making this compiler?
Thanks again for the time

[krauthaufen]

Hey, sadly Model-Types need to be in a separate file due to our compiler plugin. So sadly you must put model and app in different files atm. actually I've been annoyed by that a billion times but couldn't figure out a better way...

[dallinbeutler]

oh ok. good to know! I wish I knew how to help, but it's quite deeply embedded in things I'm still learning.
Should I leave this issue open, as a reference for others of this limitation, or close it?