Front page | perl.ldap |
Postings from April 2003
Revised proposal [was: Re: Subclass proposal: Net::LDAP::Simple]
Thread Previous
|
Thread Next
From:
Marco Marongiu
Date:
April 30, 2003 07:46
Subject:
Revised proposal [was: Re: Subclass proposal: Net::LDAP::Simple]
Message ID:
3EAFE1D2.1060004@crs4.it
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 http://search.cpan.org/perldoc?Class::Delegation
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
--
Marco Marongiu Email: bronto@crs4.it
CRS4 Research Center Phone: +39 070 2796 336
NCS Division Fax: +39 070 2796 216
NSM Group WWW: http://bugs.unica.it:4444/
Thread Previous
|
Thread Next