Re: [Soaplite-devel] SOAP::Client

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

Thread view

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

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
<scott@...>

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

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 <rlandrum@...> 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
> Soaplite-devel@...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/

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

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
> Soaplite-devel@...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details