What if the same module were going to be doing a lot of other features as well?

I agree with Aristotle on this. Something like Business::Shipping is more obvious than Business::Ship is. I too had a moment of uncertainty when I first saw the node title. Your intent is to implement a generic "shipping" API right? :-)

"Package" doesn't represent a physical package, really, but more of a "what does the carrier think of a package as?"

I guess I'm suggesting that maybe the package really should represent the physical package. All packages have things that, at least from your perspective (or that of any client using your module), are the same no matter what shipper is chosen. Packages have an origin, a destination, a weight, dimensions, contents, a value, etc. None of those is determined by the shipper. Collectively, these variables represent everything you know about the package; if the shipper were to ask you questions about the package, this is the information you'd generate your answers from.

Other vendors think of a package as only one part of a larger shipment.

So, it sounds like a "shipment" is another useful abstraction. It would be shipper-specific and so you probably would have a Business::Shipping::<carrier>::Shipment package defined for each carrier. A shipment would contain one or more packages. It would have an origin or destination just as the packages it contains. In fact, you'd probably want to assert that the packages in a shipment all had the same origins and destinations. The shipment would have a schedule attached to it. You'd likely track the shipment (rather than tracking a package.) I suspect you would want to avoid instantiating a Shipment until after one is actually scheduled; you shouldn't need these classes to determine the shipping rates.

One of the keys to building a successful API is to base it around the perspective of the API's consumers. FedEx isn't going to be using your API, www.yetanotherlittlewebstore.com is... and they don't care how the individual shippers think of packages (or shipments.) They just want to be able to write code that naturally follows from the way they handle packages. Your API should hide the differences between shippers.

When you walk into the Post Office or a FedEx office, you say "here's my package and this is where I want it to go; how much will that cost?" Your API should be true to that. If a shipper requires more specific information, your clients (those using your module) should be able to query the shipper to determine what information is needed. That way YALWS.com can ask those questions directly of their customers via some inputs on a form.

I hope that better explains why I'm wary of your current <carrier>::Package" objects.

-sauoq
"My two cents aren't worth a dime.";

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.