Re: Email::Classifier: not dead yet

2008-12-01 Thread Simon Wistow
On Mon, Dec 01, 2008 at 07:15:20PM -0500, Ricardo SIGNES said:
 I may sit on it for another week or so, but unless I get some feedback on the
 order of no, stop, this is crazy! I am going to release it and start using 
 it
 for things.  Your input is hereby requested!

This is more a point of philosophy and should probably be rephrased as a 
question but - the original goal of the Email project when I helped 
start it was to be as fast and lightweight as possible with as few 
non-core dependencies as could possibly be gotten away with[*]. 

As far as I can tell from a quick glance Classifier could be trivially 
rewritten to use absolutely no non-core dependencies - I know Moose is 
the flavour du jour but I'm still sad to the original goal abandoned.

But hey, this is your baby now (and has been for a long time) so I 
suppose I have no right to grouse. 

Simon

[*] Email::Store being the glaring counterexample and even that 'only' 
used 4 non-core, non-Email modules


Re: Email::Classifier: not dead yet

2008-12-01 Thread Ricardo SIGNES
* Simon Wistow [EMAIL PROTECTED] [2008-12-01T20:45:53]
 On Mon, Dec 01, 2008 at 07:15:20PM -0500, Ricardo SIGNES said:
  I may sit on it for another week or so, but unless I get some feedback on
  the order of no, stop, this is crazy! I am going to release it and start
  using it for things.  Your input is hereby requested!
 
 This is more a point of philosophy and should probably be rephrased as a 
 question but - the original goal of the Email project when I helped 
 start it was to be as fast and lightweight as possible with as few 
 non-core dependencies as could possibly be gotten away with[*]. 

I have long been toying with putting much of this stuff under something other
than Email, but it's sort of a moot point.  There is plenty of garbage under
Email::, of varying sorts.  There's old-school let's be simple Email:: code
that is so badly designed as to be unsalvageable and there's code from people
who know nothing of the origins of Email:: and just thought it was the right
place to put their big, reasonable email-related code.

I think that having a top-level namespace that was supposed to all be for one
related project's set of code was a failure when (a) a common noun was chosen
(b) the actual project code was not built to clearly all go together.

That said, I do keep that original goal in mind, and the email-specific
Classifier code may well be Mail::Classifier or something.  Until today,
Email::Classifier's code was not Moosified.  Making it Moose saved me a lot of
crap code.  Making it generic is also going to be useful, I know already.

 As far as I can tell from a quick glance Classifier could be trivially 
 rewritten to use absolutely no non-core dependencies - I know Moose is 
 the flavour du jour but I'm still sad to the original goal abandoned.

It's true, it could be, but extending it would be more of a pain, I'd need to
test much more of its behavior, etc etc etc.

I resisted Moose at work for quite a long time, maybe a year or more, before
giving in and realizing how incredibly useful it is and how much time it saves
me.  Then there's Mouse, which gets you quite a lot of that, with no prereqs.

Anyway, I don't mean to sound touchy, but I promise you that I resisted using
Moose for anything in E/mail for a -long- time.  I still plan to avoid it for
the Email::Send replacement.

My current guiding principle is If you want to use it in some random code that
deals with email, be as slim as possible.  If you are going to use it for
something that's really just about doing email and doing it well, don't mess
around.

If that means I'm supposed to use Mail::, then... so be it.  It just seems like
at some point Mail will start relying on Email and nobody will get it but the
cabal.

 But hey, this is your baby now (and has been for a long time) so I 
 suppose I have no right to grouse. 

Your grousing is always welcome!

-- 
rjbs