From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-05-17T04:37:09+09:00
Subject: Re: Net::LDAP filters

------=_Part_99662_4305454.1147808225965
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ah, I see the point. Interesting. I guess you're right, you probably
wouldn't need the array if you were supplying a block! Maybe we'll keep the
:return_result flag but default it to false when a block is given.

Did you have any other problems with the unreleased version of the library
that I sent you? There's actually a lot of new behavior in there that hasn'=
t
been documented yet :-). (We're trying to make the LDAP API a lot more
streamlined and intuitive.)

On 5/16/06, Andre Nathan <andre@digirati.com.br> wrote:
>
> On Wed, 2006-05-17 at 04:14 +0900, Francis Cianfrocca wrote:
> > The point of being able to turn off the result set is to save memory
> > when the set is very large. The performance improvement is potentially
> > very large.
>
> Yeah, I understand that. What I suggested was that the decision to
> return the full result set can depend only on wether a block is passed
> or not, like
>
> results =3D ldap.search(...) # no block, return full result set
>
> or
>
> ldap.search(...) { |entry|  ... } # a block was given, return nil
>                                   # (like File#open, for example)
>
> That is, only return the result set if no block is given. I suggested
> this because when you process each entry on the block you usually don't
> use the result set returned anyway. Unless there's some situation where
> you need to do
>
> results =3D ldap.search(...) { |entry| ... }
>
> then I see why the flag is useful, but I couldn't think of a situation
> where I'd need that.
>
>
> > Thanks again for the testing you did.
>
> Thank you for the great lib and the quick support!
>
> Andre
>
>
>

------=_Part_99662_4305454.1147808225965--