Thanks, So just to confirm, we can try to enforce method call parenthesis in conditionals (Does any one else have any objections?)
On a related note, As Adrien noted, there are a few legitimate use cases for `and` and `or` keywords, where they function as control flow operators, and help readability: e.g `cmd x or return nil` or `do_x or raise 'error'`, which can be replaced with if/unless but I wonder how much it will gain us in terms of readability. I think it would be nice to leave them alone. Any thoughts in this regard? On Mon, Aug 11, 2014 at 8:50 AM, Henrik Lindberg <[email protected]> wrote: > On 2014-11-08 17:44, Rahul Gopinath wrote: >> >> I agree with leaving () out for the DSL usage. >> >> Are there any such instances of DSL usage within conditionals >> (if/unless/while...)? If not, would you be in favor if we restrict the >> enforcement to conditionals only? >> >> > I think that would be rare (if at all in our code base at least). > > - henrik > > >> >> On Mon, Aug 11, 2014 at 7:00 AM, Henrik Lindberg >> <[email protected]> wrote: >>> >>> On 2014-11-08 2:01, Kylo Ginsberg wrote: >>>> >>>> >>>> On Sat, Aug 9, 2014 at 9:45 AM, Henrik Lindberg >>>> <[email protected] <mailto:[email protected]>> >>>> >>>> wrote: >>>> >>>> On 2014-09-08 24:13, Andy Parker wrote: >>>> >>>> On Fri, Aug 8, 2014 at 3:11 PM, Rahul Gopinath >>>> <[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> >>>> wrote: >>>> >>>> While correcting AndOr, I come across methods calls such >>>> as >>>> `if >>>> value.is_a? FixNum or value.is_a? Integer` >>>> >>>> How should we parenthesize it? is it `(value.is_a? FixNum) >>>> || >>>> (value.is_a? Integer)` or should it be >>>> `value.is_a?(FixNum) >>>> || >>>> value.is_a?(Integer)` ? >>>> >>>> >>>> value.is_a?(FixNum) >>>> >>>> Parens around the method arguments are the clearest fix and we >>>> should >>>> put them in everywhere IMO :) >>>> >>>> >>>> +1, except in internal DSL like logic where it reduces readability >>>> >>>> >>>> I definitely agree on the parentheses example above. >>>> >>>> Wrt requiring parens around method arguments *everywhere*, I have to >>>> admit I've wanted that at times when reading puppet code, but I also >>>> suspect it would be very high touch and perhaps controversial. >>>> >>>> And it sounds like we don't have consensus on that one. Henrik, can you >>>> give an example or two where it would reduce readability? That might >>>> help guide the discussion a bit. >>>> >>>> >>> The first that comes to mind is spec tests - it feels like you are using >>> a >>> different language than ruby, but it is really a bunch of method calls >>> without parentheses. >>> >>> i.e. do you want to write it like this? >>> >>> context("this context") do >>> it("the thingy can ...") do >>> ... >>> end >>> end >>> >>> IMO, that adds no value at all. >>> >>> In models: >>> >>> class Program < PopsObject >>> contains_one_uni 'body', Expression >>> has_many 'definitions', Definition >>> has_attr 'source_text', String >>> has_attr 'source_ref', String >>> has_many_attr 'line_offsets', Integer >>> has_attr 'locator', Object >>> end >>> >>> In the new function API: >>> >>> dispatch :handle_enumerable do >>> param 'Any', :enumerable >>> param 'Hash', :options >>> end >>> >>> Enforcing () in places like these sort of goes against the idea of using >>> an >>> internal DSL. >>> >>> >>> - henrik >>> >>> -- >>> >>> Visit my Blog "Puppet on the Edge" >>> http://puppet-on-the-edge.blogspot.se/ >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To view this discussion on the web visit >>> >>> https://groups.google.com/d/msgid/puppet-dev/lsaiai%24f9r%241%40ger.gmane.org. >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> > > > -- > > Visit my Blog "Puppet on the Edge" > http://puppet-on-the-edge.blogspot.se/ > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/lsaoop%24107%241%40ger.gmane.org. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CA%2BemFfzcMrOytP9zEy%3DS-rSET_12g0NDZwHmVULcZsK6S5n9-A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
