|Think about Loose Coupling|
Re^10: RFC: Proofread the POD for my HTML elements moduleby Don Coyote (Pilgrim)
|on May 03, 2013 at 10:05 UTC||Need Help??|
i have removed the tabs, and on test running discovered a bigger problem
using the synopsis example provided, You can clearly see that html passes a tab value, and then a CODEREF. However the html function itself expects two values. And proceeds to behave as if no coderef was even passed to it.
As this is a major obstacle, going beyond the implementation of tab indentation, I think it would be a good idea to get your take on this. Did your synopsis run through the Element.pm module ok for you?
short while passes...
Ok I just saw your thread on coderefs, so you are aware of this. The solutions provided are fairly robust. I have also been thinking about alternate approaches.
What though is the problem? At this stage I see the 'problem' to be twofold.
The first point is something that I keep getting told is the most relevantissue, so should be borne in mind throughout the process. Is this module necessary, does HTML require to be programmatically produced etc..
The second point underlies what i think is the main source of bafflement in this task. Why? are you passing coderefs?
And how would the module provide an advantage to a user over staticly writing HTML? Or more appropriately, using an existing module?
I think the issue to confront is, what does the user want to do, and what does the module provide. I have some thoughts inspired by hacking on your module, and from experience of HTML production. I think they could tie in easily at this stage, to produce something simpler.
To start with, every module i see so far seems to treat the HEAD's elements as only needing one function. Yet BODY's children all get their own functions.
And so on, HTML as a function, recieving HEAD and BODY as its arguments. Each, recursing into each childs elements function or parameters intil a swamp of refs consume all. If this is to be a functional module why not keep it functional?