develooper Front page | perl.ldap | Postings from April 2003

Revised proposal [was: Re: Subclass proposal: Net::LDAP::Simple]

Thread Previous | Thread Next
Marco Marongiu
April 30, 2003 07:46
Revised proposal [was: Re: Subclass proposal: Net::LDAP::Simple]
Message ID:
Graham Barr wrote:
>>>On Mon, Apr 28, 2003 at 12:53:55PM +0200, Marco Marongiu wrote:
>>>If there is one thing that concerns me is that it is implemented
>>>by inheritance.  inheritance is usually, in my experience, used to
>>>extend functionality of a class. But in this case you are changing
>>>it. By that I mean you have overridden methods and changed their
>>>functionality by changing the return type.

Actually, this is true just for the constructor (and how could it be 
otherwise?) and the search method -for which, anyway, I put a note about 
the fact that it redefines the return type:

>         NOTE: Actually, I am undecided if this is a good thing. I am
>         pondering if search should simply be inherited by the
>         superclass... I'd like to have some feedback about that. 

On the contrary, add and delete work the same way as before when called 
with the syntax $ldap->add(DN[,OPTIONS]) and DN is a scalar. Anyway, I 
see your point, and it could be easy to rename the "guilty" methods to 
add_many and delete_many -that should resolve the issue by 
C.A.Bongaarts, too.

Last, search could be "remapped" to have the same return type of the 
parent class, while allowing it to take advantage of new()'s parameter 
"base" and automatic filter creation. That way, one could still use 
->search the Net::LDAP way.

>>>What I would suggest is that the Net::LDAP object become a property
>>>of your object and not inherit.
>>That's what I did at first. Then I realized that I needed all functionalities 
>>of Net::LDAP that I didn't reimplement, and I thus had to proxy every unknown 
>>method back to Net::LDAP. That called for my module to be a subclass rather 
>>than a "composition".
> I dont think that means it should be a sub-class. You need to use delegation
> for those methods. See

I read the docs of Class:Delegation and I'll surely consider 
implementing Net::LDAP::Simple (or whatever name we'll christen it with) 
using it, but not in the short term. I'd switch to delegation for one 
main reason: I don't like to rely on the internal structure of the 
parent object: if, for any reason, you'll change the implementation of 
the object (e.g.: from hash to array) my subclass won't work anymore.

So, seen the feedback of this mailing list, my revised proposal is:

* rename {add,delete} methods as {add,delete}_many
* modify search to be Net::LDAP compatible
* add an onlyattrs parameter to new()
* implementing the module as a subclass
* calling the module Net::LDAP::Extended

If this is acceptable and no more defects will be pointed out, I'll 
modify the class and publish it in the next few days.

As always, feedback is gladly accepted.

Thanks again

Marco Marongiu                         Email:
CRS4 Research Center                   Phone: +39 070 2796 336
NCS Division                           Fax:   +39 070 2796 216
NSM Group                              WWW:

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About