This reminds me -- in Lift, I've frequently seen the pattern of
utilizing a companion object's apply() methods as factories. Perhaps
it's just me, but this seems a little less intuitive than having an
explicitly named constructor method that is in some way descriptive of
the state in which the related object is being created. Is this just a
Scala idiom that I'm going to have to get used to? It seems
particularly strange because the use of apply() in this fashion is not
necessarily consistent; for example, the apply() usage of AnyVar and
its subclasses delegates to setFunc, which mutates an underlying data
structure. I sort of wish I could just call myRequestVar.set(myValue)
instead; that has a lot more semantic meaning to me when I'm scanning
code than does myRequestVar(myValue).
Kris
On Wed, Sep 24, 2008 at 9:48 AM, David Pollak <[EMAIL PROTECTED]> wrote:
>
>
> Kris Nuttycombe wrote:
>
> If you're going to take that approach, why not just make the
> constructor or factory method ensure that the object is in a valid
> state to begin with? When I write immutable objects, they usually
> don't have any setters for that very reason. It doesn't make sense to
> me that one would construct a PayPal object in an unusable state.
>
>
> Agreed. The initial "builder" (no longer using the word Constructor per
> Viktor's suggestion) should vend an object that can be used. Any additional
> state (e.g., useSSL) should return a new instance of a mutated object.
>
> As to Viktor's suggestion, having a bunch of builder methods on an object
> rather than an explicit constructor is the right way to go. e.g.:
>
> trait PayPal {....}
>
> object PayPal {
> def apply(....): PayPal = ....
> }
>
> Kris
>
> On Tue, Sep 23, 2008 at 7:46 PM, David Pollak <[EMAIL PROTECTED]> wrote:
>
>
> Tim,
>
> I like the work, but I tend not to like mutable data structures (stuff with
> properties that one sets.) I'd structure things such that the PayPal
> object's "setters" return a new, immutable instance of the PayPal object, so
> you're code would look like:
>
> val pp: PayPal = new
> PayPal("sandbox").transactionToken(S.param("tx")).useSSL(true)
>
> I'd also update the "execute" method so that it returns another immutable
> object that has current state rather than mutating the original PayPal
> object.
>
> Thanks,
>
> David
>
> Tim Perrett wrote:
>
> Thanks Derek :-) I have commited any code for ages, so its about time
> I did!
>
> My plan is this - once I get this roll out of the site im doing now
> (which just needs PDT) done, I'll add the IPN functions to it. From
> the docs, it looks pretty straight forward.
>
> You can configure a whole bunch of options like so:
>
> /* values can be "sanbox" or "live" */
> var paypal: PayPal = new PayPal("sandbox")
> /* self expanitory */
> paypal.transactionToken = S.param("tx").openOr("")
> /* set if you need to use SSL (changes port and protocol) */
> paypal.useSSL = true
> /* run the paypal transaction - either with a PDT payload or IPN
> payload */
> paypal.execute("pdt")
>
> Anything else / different way of doing it people think I should build
> in?
>
> Tim
>
> On Sep 23, 6:24 pm, "Derek Chen-Becker" <[EMAIL PROTECTED]> wrote:
>
>
> Tim, you rock :)
>
>
>
>
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
