Re^2: Python OO v Moose

The single quote strangeness was due to a copy/paste from GoogleDocs. I'll have to keep that in mind when using that to share code. The """ is starting to make more sense now. I'm not sure if I have any preferences for documentation style yet. I like POD for the space it gives the text, except when I don't want to look at it, especially since I tend to prefer keeping the documentation near the methods. Javadoc is easily hidden in Eclipse, but I'm a little put off by its differentness. I haven't seen a style that really grabs me so far.

I was in two minds in the printargs method. It looks better the way you've written it. I was trying to keep it simple so that people with no knowledge of Perl could see how it works, but I do like the for line. Likewise, I'd used lots of whitespace in the attribute distributions to make it 'friendlier'.

Sometimes I can think of 6 impossible LDAP attributes before breakfast.

Comment on Re^2: Python OO v Moose Select or Download Code

Replies are listed 'Best First'.
Re^3: Python OO v Moose by tobyink (Canon) on Feb 06, 2013 at 13:09 UTC
I used to intersperse my pod and code, but eventually grew to dislike that, so now place all my pod at the end of the file. Yes, there's something to be said for keeping documentation and code close together, but having them in the same file is close enough for me. Putting all the pod at the end I think encourages me to write documentation that flows better as a document - making the pod less a list of methods, and more a how-to. `package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name`	[reply]

Replies are listed 'Best First'.

Re^3: Python OO v Moose
by tobyink (Canon) on Feb 06, 2013 at 13:09 UTC

I used to intersperse my pod and code, but eventually grew to dislike that, so now place all my pod at the end of the file.

Yes, there's something to be said for keeping documentation and code close together, but having them in the same file is close enough for me. Putting all the pod at the end I think encourages me to write documentation that flows better as a document - making the pod less a list of methods, and more a how-to.

package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name

[reply]