You're correct for not-nullable contract types. I agree that it is less
obvious. But on the other side it simplifies contract understanding because
otherwise developer needs to know not only how null is treated but also how
NoValue is treated. This also make UI development easier as with null equal
Got it.
What about this "it is easier to set attribute value to None rather then
deleting attribute from object if default value is desired, especially for
generic clients"?
Do I understand correctly that setting some property to None should leads
to automatic assignment of the default value?
As f
Hi Alex,
1. This is directly related to the bug mentioned above.
Taking an example from launchpad
networks:
Contract:
environment: $.bool().notNull()
flat: $.bool().notNull()
custom: [$.class(Network).notNull()]
Default:
environment: true
flat: false
curr
Hi Stan,
I don't understand well your third problem/solution statement. Could you
please give an example of the proposed behaviour vs the current one?
The last solution - to have not-nullable primitive types by default - looks
good to me, but it breaks the compatibility with the existing contract
Hello everyone!
Recently I've been looking for a best way to fix incorrect handling of
defaults in MuranoPL's property contracts [1]. I analyzed how contracts
used in applications that are currently in app-incubator, typical mistakes
and usage patterns. I've found number of places where contract s
