soaplite-devel

[Soaplite-devel] SOAP::Client

[Martin K. <mar...@fe...>]

Hi there,

around line 2250 in SOAP/Lite.pm, there's the package SOAP::Client.

It creates a bunch of setter/getter methods, like this:

 *$method = sub {
   my $self = shift->new;
   @_ 
	? ($self->{$field} = shift, return $self) 
	: return $self->{$field};
 }

I stumbled across the first line of these methods today, when writing a
loopback test transport backend: It calls the transport backend's new() 
every time one of these methods is called, regardless of whether it's
been called before.n

In my opinion, this introduces two misbehaviours:

a) the constructor new() is frequently called as an object method -
which is a perlish, but nonetheless bad habit

b) all initialization (or whatever a user has done to the transport
layer between calling new() and the next method call) is lost, as
there's alway a fresh method there.

This means that users cannot set LWP::UserAgent's characteristica by
calling $soap->transport->some_lwp_method(1);, because send_receive (at
least in the HTTP transport class) might call $self->endpoint, and thus
operate on a new object.

Are there any reasons for SOAP::Client behaving like this ? If not, I'd
change the line to 

 my $self = ref $_[0] ? shift : shift->new();

which also guarantees there's a valid SOAP::Client object, but does not 
override existing ones.

This might induce subtle side effects, even though there's no effect on
the test suite.

Any opinions ?

Marti

Re: [Soaplite-devel] SOAP::Client

[Scott W. <sc...@pe...>]

On Thu, Oct 04, 2007 at 12:44:06PM +0200, Martin Kutter wrote:
> Hi there,
> 
> around line 2250 in SOAP/Lite.pm, there's the package SOAP::Client.
> 
> 
> Are there any reasons for SOAP::Client behaving like this ? If not, I'd
> change the line to 
> 
>  my $self = ref $_[0] ? shift : shift->new();

I don't use S::C, but I agree with your assessment and solution.
> 
> This might induce subtle side effects, even though there's no effect on
> the test suite.

Without a test, the user hasn't ever had a guarantee. Perhaps you can
make a test that would trigger a fault as the code exists now, you
implement your fix, and push out a few provisional releases so some
S::C users could try it out for you.

Scott
-- 
Scott Wiersdorf
<sc...@pe...>

Re: [Soaplite-devel] SOAP::Client

[Robert L. <rla...@ao...>]

Martin Kutter wrote:
> 
> b) all initialization (or whatever a user has done to the transport
> layer between calling new() and the next method call) is lost, as
> there's alway a fresh method there.
> 
> This means that users cannot set LWP::UserAgent's characteristica by
> calling $soap->transport->some_lwp_method(1);, because send_receive (at
> least in the HTTP transport class) might call $self->endpoint, and thus
> operate on a new object.

I noticed this too...  But I tracked the new method back and it appears 
to actually do the right thing...  Depending on the inheritance of 
SOAP::Client, that is...

In other words, almost all the $obj->new methods in Lite.pm do the 
following...

sub new {
   my $self = shift;
   return $self if ref $self;
   ...
}

So the new method isn't really creating new objects, which is definitely 
confusing...  :)

Rob

Re: [Soaplite-devel] SOAP::Client

[Paul K. <pau...@ya...>]

Martin/Rob,

As far as I remember, this was to allow someone to create objects
with:

CLASS->endpoint(...)

rather than

CLASS->new->endpoint(...)

with both $obj->endpoint(...) and $obj->new->endpoint(...) still
working as expected.

We should probably have something in the tests to cover this. I
remember this technique being used in examples. Probably went too far
in my quest for simplification.

> > calling $soap->transport->some_lwp_method(1);, because
> send_receive (at
> > least in the HTTP transport class) might call $self->endpoint,
> and thus
> > operate on a new object.

As Rob mentioned, this should still work as a new object is only
created for a CLASS call.

Paul.

--- Robert Landrum <rla...@ao...> wrote:

> Martin Kutter wrote:
> > 
> > b) all initialization (or whatever a user has done to the
> transport
> > layer between calling new() and the next method call) is lost, as
> > there's alway a fresh method there.
> > 
> > This means that users cannot set LWP::UserAgent's characteristica
> by
> > calling $soap->transport->some_lwp_method(1);, because
> send_receive (at
> > least in the HTTP transport class) might call $self->endpoint,
> and thus
> > operate on a new object.
> 
> I noticed this too...  But I tracked the new method back and it
> appears 
> to actually do the right thing...  Depending on the inheritance of 
> SOAP::Client, that is...
> 
> In other words, almost all the $obj->new methods in Lite.pm do the 
> following...
> 
> sub new {
>    my $self = shift;
>    return $self if ref $self;
>    ...
> }
> 
> So the new method isn't really creating new objects, which is
> definitely 
> confusing...  :)
> 
> Rob
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



       
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell. 
http://searchmarketing.yahoo.com/

Re: [Soaplite-devel] SOAP::Client

[Robert L. <rla...@ao...>]

Paul Kulchenko wrote:
> Martin/Rob,
> 
> As far as I remember, this was to allow someone to create objects
> with:
> 
> CLASS->endpoint(...)
> 
> rather than
> 
> CLASS->new->endpoint(...)
> 
> with both $obj->endpoint(...) and $obj->new->endpoint(...) still
> working as expected.
> 

What follows is opinion, and not a change request.

I've always found CLASS->method to be very confusing to use.  I also 
find object nesting confusing... i.e. 
CLASS->method(args)->other_method()->result.

I think the loose object model actually leads to more confusion rather 
than making the module easier to use, because theres just TOO MANY ways 
to do the same thing.  And when following a standard protocol, in this 
case SOAP, having lots of different interpretations really defeats the 
purpose.

The LWP method of creating multiple objects for your user agent and 
envelope is more along the lines of what I would expect with a SOAP 
implementation.  This would also allow for error checking at different 
levels of the transport, something I've never quite managed to get right 
with SOAP lite.

Rob

Re: [Soaplite-devel] SOAP::Client

[Martin K. <mar...@fe...>]

Hi there,

As Rob pointed out, most new() methods currently do what I have proposed
(but at some other place).

As there's nobody here telling me that calling new() every time is
important, I'll just implement the proposed alternative.

Im not going to work over the whole SOAP-Lite package to make this
consistant, though - at least not now.

Thanks for your comments,

Martin

Am Donnerstag, den 04.10.2007, 12:44 +0200 schrieb Martin Kutter:
> Hi there,
> 
> around line 2250 in SOAP/Lite.pm, there's the package SOAP::Client.
> 
> It creates a bunch of setter/getter methods, like this:
> 
>  *$method = sub {
>    my $self = shift->new;
>    @_ 
> 	? ($self->{$field} = shift, return $self) 
> 	: return $self->{$field};
>  }
> 
> I stumbled across the first line of these methods today, when writing a
> loopback test transport backend: It calls the transport backend's new() 
> every time one of these methods is called, regardless of whether it's
> been called before.n
> 
> In my opinion, this introduces two misbehaviours:
> 
> a) the constructor new() is frequently called as an object method -
> which is a perlish, but nonetheless bad habit
> 
> b) all initialization (or whatever a user has done to the transport
> layer between calling new() and the next method call) is lost, as
> there's alway a fresh method there.
> 
> This means that users cannot set LWP::UserAgent's characteristica by
> calling $soap->transport->some_lwp_method(1);, because send_receive (at
> least in the HTTP transport class) might call $self->endpoint, and thus
> operate on a new object.
> 
> Are there any reasons for SOAP::Client behaving like this ? If not, I'd
> change the line to 
> 
>  my $self = ref $_[0] ? shift : shift->new();
> 
> which also guarantees there's a valid SOAP::Client object, but does not 
> override existing ones.
> 
> This might induce subtle side effects, even though there's no effect on
> the test suite.
> 
> Any opinions ?
> 
> Marti
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>