Hunter Haugen <hun...@puppetlabs.com> writes: >> Ouha! I didn't know that property could have parent class defined. >> This is nice. Does it work also for parameter ? > > I haven't tried, but property is just a subclass of parameter so > truthy could probably be made a parameter then become a parent of > either a property or a parameter.
I will make a test tomorrow and report back how it goes, but you're right, it should be ok. > >> >> The NetScalerTruthy is more or less what would be needed for thruthy stuff. >> >> On my side I came up with this solution (for different stuff, but the >> same principle could be used here as well): >> >> https://review.openstack.org/#/c/238954/10/lib/puppet_x/keystone/type/read_only.rb >> >> And I call it like that: >> >> newproperty(:id) do >> include PuppetX::Keystone::Type::ReadOnly >> end >> >> I was thinking of extending this scheme to have needed types (Boolean, >> ...): >> >> newproperty(:truth) do >> include PuppetX::Openstack::Type::Boolean >> end >> >> Your solution in NetScalerTruthy is nice, integrated with puppet, but >> require a function call. > > The function call is to a) pass documentation inline (since I assume > every attribute has different documentation so didn't want to hardcode > it in the truthy class), and b) pass the default truthy/falsy values > that should be exposed to the provider (ie, allow you to cast all > truthy values to `"enable"` and `"disable"` instead of only supporting > `true` and `false`. > > The truthy class could obviously be implemented such that if no block > is passed to the attribute then the method is automatically called > with default values, then you wouldn't even need the `include` mixin. That's look like a perfect interface. I'm going to try this on some code. I will report here tomorrow, hopefully in a small review :) Thanks again for those great insights. >> >> My "solution" require no function call unless you have to pass >> parameters. If you have to pass parameter, the interface I used is a >> preset function. Here is an example: >> >> https://review.openstack.org/#/c/239434/8/lib/puppet_x/keystone/type/required.rb >> >> and you use it like this: >> >> newparam(:type) do >> isnamevar >> def required_custom_message >> 'Not specifying type parameter in Keystone_endpoint is a bug. ' \ >> 'See bug https://bugs.launchpad.net/puppet-keystone/+bug/1506996 ' >> \ >> "and https://review.openstack.org/#/c/238954/ for more >> information.\n" >> end >> include PuppetX::Keystone::Type::Required >> end >> >> So, modulo you can have parameter with parent, both solutions could be >> used. Which one will it be: >> - one solution (NetScalerTruthy) is based on inheritance, mine on >> composition. >> - you have a function call to make with NetScalerTruthy no matter what; >> - you have to define function to pass parameter with my solution (but >> that shouldn't be required very often) >> >> I tend to prefer my resulting syntax, but that's really me ... I may be >> biased. >> >> What do you think ? >> >>> >>> On Mon, Nov 2, 2015 at 12:06 PM Cody Herriges <c...@puppetlabs.com> >>> wrote: >>> >>> Sofer Athlan-Guyot wrote: >>> > Hi, >>> > >>> > The idea would be to have some of the types defined oslo config >>> > >>> >>> http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/types. >>> py >>> > ported to puppet type. Those that looks like good candidates >>> are: >>> > - Boolean; >>> > - IPAddress; >>> > and in a lesser extend: >>> > - Integer; >>> > - Float; >>> > >>> > For instance in puppet type requiring a Boolean, we may test >>> > "/[tT]rue|[fF]alse/", but the real thing is : >>> > >>> > TRUE_VALUES = ['true', '1', 'on', 'yes'] >>> > FALSE_VALUES = ['false', '0', 'off', 'no'] >>> > >>> >>> Good idea. I'd only add that we should convert 'true' and 'false' >>> to >>> real booleans for Puppet's purposes since the Puppet language is >>> now typed. >>> >>> -- >>> Cody >>> >>> ___________________________________________________________________ >>> _______ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> -- >> Sofer Athlan-Guyot >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> -- Sofer Athlan-Guyot __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
