Re: new version of perl-ldap-0.20

[Graham B. <gb...@po...>]

On Tue, Aug 15, 2000 at 01:47:07PM +1000, David Bussenschutt wrote:
> Hi again,
> 
> Why not handle the 'expected'?  

What is expected ?

> What happens when compare has (for example) an internal error and/or the
> data was uncomparable for unknown reason?  Is this handled at the moment?
> It should in my opinion be this is what could/should cause an on_error
> event in compare's case. 

It returns the error from the server. It is up to the application to determine
what to do with that error.

> And for that matter, by allowing a user-defined subroutine as an on_error,
> you could allow the user(programmer) to define a callback for 'compare'
> that dies/croaks/whatever whenever the user(programmer) desires (including
> error code 5 or 6).

Hm, maybe more thought is needed here.

> By doing this the API is simpler,

really ?

> the bloat is negligable,

Not really

> the users are
> happier,

may be

> the resultant code is easier to read... what more could you want?

beauty is in the eye of the beholder.

> I mean, the "|| die.." code will be written anyway so in the module is a
> better place for it, so it doesn't have to be written over and over again! 

But it is not being written in the module, the user is having to write
a sub to process the result. All you are doing is moving when the user processes
the result.

> As I understand it, this would also clear-up the problem the API currently
> has with it's inability to determine if a search returned no results

What inability ? $mesg->count will teel you how many results you got.

> because there was nothing to return or because of an error performing the
> search.

You are referring to getting values from an entry, a separate module from the
LDAP API module

Graham.