Refer to .content method for Pod blocks rather than .contents

[lizmat]

content 2 |ˈkɒntɛnt| noun (also contents) the things that are held or included in something: she unscrewed the top of the flask and drank the contents. • [ in sing. ] [ with modifier ] the amount of a particular constituent occurring in a substance: soya milk has a low fat content. • (contents)a list of the chapters or sections given at the front of a book or periodical: [ as modifier ] : the contents page. • [ mass noun ] the material dealt with in a speech, literary work, etc. as distinct from its form or style: the tone, if not the content, of his book is familiar.

• information made available by a website or other electronic medium: [ as modifier ] : online content providers.

Feels to me that .contents more accurately describes the functionality of this method, than just .content

[hoelzro]

@lizmat I could go either way, but I thought I would invoke the programmer virtue of Laziness and change two lines of the spec to what's implemented to avoid changing the compiler and any existing code using .content. =)

[Mouq]

The argument for .contents that I personally see is that .content always returns an Array, and I think the plural conveys this better. OTOH, a serious amount of code already uses .content (since high-level interfaces to Pod objects have only started being worked on recently), and I don't think the slight semantic improvement is worth the cost of deprecation here.

[hoelzro]

If only we had a Perl 6 code search to see how many modules actually use this...

[dwarring]

+1 for ,contents

Chances are that affected modules need to adjust pod comments anyway.

[moritz]

fwiw perl6/doc extensively works with the pod tree.

Either way, if the implementation changes, we can simply provide both for a while, and then deprecate the old one.

+1 for contents from me.

[hoelzro]

I'll close this then, and strive for contents!