Re: [Htmlparser-developer] factories and prototypes

[Joshua K. <jo...@in...>]

Derrick Oswald wrote:

> The NodeFactory is an interface, 

Your NodeFactory is an interface.  I'm not interested in your 
NodeFactory, as I don't like its implementation.  When I refer to 
NodeFactory, it's my StringNodeFactory with the name, NodeFactory.

> you don't subclass an interface, you implement it. 

Have you considered a career in teaching the Java language?   

> People can write their own three method class to do that, or like I 
> said, delegate to the parser for things they don't want to handle. 

Nah.  People will clearly see a *class* called NodeFactory, which will 
have numerous methods on it for configuring the primitive types, like 
StringNode, Tag, etc.  I know you love your new lexar, but we aren't 
gonna make folks get access to the lexar to set a NodeFactory -- that's 
just plain awkward, unintuitive and downright strange!

> But delegation comes at the cost of time and memory. 

Spoken like a premature optimizer!    Hey, what else does the Parser 
delegate to?  Maybe we could fold all sorts of classes into the Parser 
to create one big monster class that would be so utterly efficient.   
Wait, do you think we should re-write this thing in C?  

Show me how having a client call the parser's NodeFactory object is so 
much slower and more memory intensive than having the client call the 
parser's create methods directly.  If you cannot show a huge difference 
in time and memory,  I won't prematurely optimize my code.

> The current string decorator architecture, for example, delegates 
> through three wrapping objects (with associated memory overhead) to do 
> the job the StringNode should do in the first place. 

Easily optimized without dumping the code into StringNode -- see what I 
say about Flyweights, below.

> If one knows a priori that whitespace removal, reference translation 
> and so on are useful functions, build them into the StringNode. 
> Provide the factory mechanism only for things you can't anticipate in 
> advance. Leaving the decorator code as a caboose grafted on to the 
> base implementation is only acceptable if it's a transient fix.

I know 5 useful functions for StringNodes.  It would be poor design to 
shove them into the StringNode, which is better off being primitive.  
The useful functions I know about are options for a StringNode.  Most 
folks don't use them.  Those that do, can decide to turn them on if they 
need them.   They can do that easily through a NodeFactory, since that 
is the perfect place to say "here's the kind of StringNodes I want you 
to create during the parse."  

> I use profilers all the time. And memory analysis. And javap to 
> examine the byte code. That's why the lexer code runs 60% faster than 
> the old NodeReader code and uses a quarter of the memory. 

Are users complaining about the speed and memory usage of the parser?   

> Are you saying the creation of objects doesn't take time and memory? 
> Maybe you should run a profiler comparing the 'decorative wrapping' 
> approach with a 'built in functionality' approach. Or better yet, just 
> step through it (and I mean step *in* to every method) in a debugger 
> and see where all the time is spent allocating and wandering between 
> objects without getting any of the work done, and repeatedly copying 
> out strings. It's a real eye-opener for someone who only works at the 
> 30,000 foot level.

The decorators on this project can easily be made into Flyweights, which 
means 3 objects can do *all* of the decoration for all of the StringNode 
objects.  That's an easy change to make and doesn't involve *shoving* 
behavior into StringNode and bloating that class with code it doesn't 
need.   It also leaves room for the Decorators to decorate other node 
types, like RemarkNode.   Or would you rather shove embellishments into 
that class as well?

> Yes, I'm a big advocate of test driven development. The bean classes 
> were dropped with their tests - BeanTest, so I don't see why you 
> couldn't refactor it. 

BeanTest!  I looked at that one.  It barely tested a fraction of 
StringNode's behavior.  It tested if you could successfully serialize a 
StringNode.  Hee haaa!   If you used TDD to program StringBean, you're 
doing something very wrong. 

> The lexer package has it's tests. There are currently 35 outstanding 
> failures out of 448 and I'm currently trying to re-integrate the test 
> cases that got shunted off to the temporaryFailures package -- because 
> someone wanted a green bar. You can still do test driven development 
> without a green bar by monitoring the number of failures...
> ...like a doctor, you just ensure you 'do no harm'.

If you had evolved the lexar into the parser, as I suggested to you in a 
private email, the bar would be green today, it would've been green 
yesterday and the day before that.   But evolutionary design isn't 
something you get, or, more probably, isn't something you even want to 
learn.

A green bar is necessary for refactoring.  Monitoring failures is not a 
habit I plan to adopt, as I find it annoying.   You don't mind making us 
all live with red tests for days on end.  So please delete the 
temporaryFailures package -- it's useless given your style of programming.

--jk