http://qs1969.pair.com?node_id=262225


in reply to Re: CPAN Module Proposal: Business::Ship
in thread CPAN Module Proposal: Business::Ship

Thanks for the input, diotalevi. The reason I picked Business::Ship was because calculating shipping cost isn't the only feature that I wanted to support. In the future, I plan to add:

* Address Verification
* Shipping status (tracking)
* Electronic Merchandise Return
* Shipping label generation
* Customs forms
* Shipping time (how long till it gets there)
* Delivery/Signature confirmation

I see that you've hardcoded various strings in your code like the following country name translator. You should either delegate this job to something else or move the data outside your program.

Good advice, I'll do that.

I also notice you use the indirect object syntax - that's likely a mistake on your part and it should be rectified.

I like the object factory design a lot, so I probably used it even though it wasn't necessary. But the idea was that it would make it easier on the API user to use UPS or USPS (eventually others) without changing much code. Namely, they can get the sub-object without doing an eval. For an example, see doc/xps-query.tag.
-Dan
  • Comment on Re: Re: CPAN Module Proposal: Business::Ship

Replies are listed 'Best First'.
Re: Re: Re: CPAN Module Proposal: Business::Ship
by sauoq (Abbot) on Jun 01, 2003 at 20:46 UTC

    diotalevi said:

    also notice you use the indirect object syntax - that's likely a mistake on your part and it should be rectified.

    Your response seemed to indicate that you didn't really understand what he meant. "Indirect object syntax" refers to calling methods like so: 

    my $obj = new Object();     # Indirect Object notation (class method)
my $ret = some_method $obj; # Indirect Object notation (instance metho
+d)

    [download]
    Using this syntax is not recommended. It suffers from several serious ambiguities. See perlobj for more information. There are also sure to be several nodes around here which warn against it.

    -sauoq
"My two cents aren't worth a dime.";
[reply]
[d/l]
      Your response seemed to indicate that you didn't really understand what he meant. "Indirect object syntax" refers to calling methods like so: 
      my $obj = new Object();     # Indirect Object notation (class method)
my $ret = some_method $obj; # Indirect Object notation (instance metho
+d)

      [download]

      Aha, you're right. Thanks. I assumed that he was referring to the fact that new Business::Ship( shipper => UPS ) actually returns a Business::Ship::UPS object (not a Business::Ship object).

      I prefer the indirect notation for constuctors because the alternative is the uglier than a VB script that uses Hungarian Notation, and hit every ugly branch when it fell off the top of the ugly tree. Besides, it hasn't bit me yet (famous last words).

      -Dan
[reply]
[d/l]
Re: Re: Re: CPAN Module Proposal: Business::Ship
by diotalevi (Canon) on Jun 02, 2003 at 01:01 UTC

    I'm following up from sauoq's note on the indirect object syntax because zie didn't provide the fixed syntax (and that's all this is - syntax).

    $obj = Class->new;

    versus

    $obj = new Class;

    You can get yourself into hot water by using the second form as its ambiguous - the first is unambiguous and works all the time.

[reply]
[d/l]
[select]
      the first is unambiguous and works all the time.

      Just to be the mega-pain, I do seem to recall that it isn't 100% unambiguous - it could mean $obj = Class()->new().

      The way to be certain I think was to use either new Class:: or Class::->new (ugly, ain't it?).

      Nope, I don't ever see it written like that either, and maybe that is how it used to be - I didn't whip up a test script since I'm too lazy. Just felt like being a bit obstinate before my coffee. ;-)

      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.
[reply]
[d/l]
[select]
[reply]

In Section Meditations