Re: [openstack-dev] [Murano] Improvements to MuranoPL contracts

2014-05-27 Thread Alexander Tivelkov
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

Re: [openstack-dev] [Murano] Improvements to MuranoPL contracts

2014-05-27 Thread Stan Lagun
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

Re: [openstack-dev] [Murano] Improvements to MuranoPL contracts

2014-05-27 Thread Alexander Tivelkov
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

Re: [openstack-dev] [Murano] Improvements to MuranoPL contracts

2014-05-27 Thread Stan Lagun
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

[openstack-dev] [Murano] Improvements to MuranoPL contracts

2014-05-26 Thread Stan Lagun
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