Re: Fwd: Re: [Platemail-developer] Properties

[David S. <ds...@in...>]

>>>
>>>>>I'm going to start a bit of Platemail hacking now.
>>>>
>>>>Good, good.  I did some poking, and I think I've gotten the basic idea
>>>>for how it's going to work.  I've implemented a little sample which
>>>>lists the Vector for Properties for pop3mailsource.  That's quite
>>>>straight forward, however I really think we need a more
>>>>organised/formal way of adding the classes that are to be saved.
>>>>
>>>>To whit;
>>>>
>>>>1) Modifying the constructors to add a reference to the registry
>>>
>>>I'd be careful with doing this in the constructor; there may be cases
>>>where you don't want to add them (though none that immediately occur). 
>>>Perhaps you
>>>
>>>could just have a register() method to be called after construction, and
>>>optionally a static method on the class which creates you a new object
>>>and registers it for you.  The other alternative is to pass a boolean
>>>flag to the
>>>
>>>constructor, but it seems to me that registration isn't really a
>>>constructor task.
>>
>>I know what you're coming from, however I'm not sure what the best thing to
>>do is.  I think that the objects need to have a reference to the registry
>>somehow, and once they've got that then they can register/deregister
>>themselves all day long.  That's the important thing which I want put into
>>the constructor, so that an outside called can just say obj.register();
>>rather than the C-style obj.register(registry).
> 
> 
> There's a static accessor method on PlatemailKernel that gives you the current 
> kernel instance, so if your registry hangs off PlatemailKernel you can get it 
> from there.  PlatemailKernel is (currently) a singleton, and if that ever 
> changes I'll change the static accessor to do the right thing.  This is 
> probably easier than passing around a reference to the registry all the time.
> 

I'd forgotten about the static kernel accessor.  I'll use that instead. 
  I have the natural distrust of static things, however that will save a 
lot of argument passing.  Lovely.

> 
>>As to adding the call to register() outside the constructor, I'm not really
>>that bothered.  It's probably a bit icky (error prone) to require a manual
>>call to the register, however without multiple inheritance there's not a
>>lot we can really do.  It would be nice to have this handled automatically.
>>
>>Maybe.
>>
>>Creating a static constructor and having that do the registration doesn't
>>seem to solve any of the problems as best I can see though, that just seems
>>to be moving the problem around.
> 
> 
> Not really, I think it gives you a separation between object construction and 
> what you do with the object once you've made it.  If you want it registered, 
> you can call, say POP3MailSource.getRegisteredMailSource(args), and if you 
> don't you can always call new POP3MailSource(args).  I imagine that the 
> former will be the common case, so you can make the constructor itself 
> private until we decide it's necessary to expose it; that'll prevent anyone 
> accidentally forgetting to register the object in the meantime.
> 

Sure.  I don't think it's that important, but you know, whatever.

> 
>>>>2) Adding
>>>>   - a Vector of properties
>>>
>>>Why not just a Properties object?
>>
>>Because I didn't realise that it's actually a list (hashtable) itself. 
>>I'll change this.
> 
> 
> Ah, OK.
> 
> 
>>>>   - a method called by the constructor (?) to populate that list
>>>>   - a method to register the properties vector
>>>>   - a method to unregister the properties vector
>>>>
>>>>Currently, I just call these methods "manually" from the class
>>>>corresponding to "addpopaccount", however these should really be
>>>>self-contained within each class.  Adding an interface to specify these
>>>>properties would probably be the best plan.
>>>
>>>OK.  Are you going to specify a common interface (PlatemailObject or
>>>RegisteredObject or something) that all filters, mail sources and so on
>>>can implement?
>>
>>Yeah, that sounds like the best plan.  I'll have to do a bit of reading up
>>about how interfaces work in Java, but I think that's reasonable.
> 
> 
> Cool.
> 
> 
>>Oh, this is off-list but that's because I've had some mail issues.  I've
>>changed my sourceforge address to work, which will be easier for me to
>>access from now on.
> 
> 
> OK.  Let me know when your OK to use the list again.
> 

Hopefully this will get to you.  If so, then everything is peachy.

> 
>>Right.  I need to book myself some flights to Madrid.
> 
> 
> Madrid, eh?  Off jet-setting?
> 

Project workshop.  Plus some sight seeing, of course.  I love working 
for the EU.

I'm off to Dublin to see Jenny the week after, however I need to pay for 
that myself unfortunately.

dgs.
-- 
David Stocks
Institute of Perception, Action and Behaviour
School of Informatics, University of Edinburgh
+44 (0)131 651 3436