<br><font size=2 face="sans-serif">>></font><font size=2 face="Courier New">Such methods did make it into one of the betas a couple of years ago. <br>
They were eventually removed on the grounds that there were just too <br>
many methods in the class. </font>
<br>
<br><font size=2 face="sans-serif">That sounds reasonable, I will stick to using my extended element class,<br>
<br>
/Phill<br>
IS Dept, Software Engineer.<br>
phill_perryman@mitel.com<br>
http://www.mitel.com<br>
Tel: +44 1291 436023</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Elliotte Rusty Harold <elharo@metalab.unc.edu></b></font>
<br><font size=1 face="sans-serif">Sent by: jdom-interest-admin@jdom.org</font>
<p><font size=1 face="sans-serif">15/07/2003 20:35</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: "William Krick" <wkrick@eio-online.com>, <jdom-interest@jdom.org></font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: Re: [jdom-interest] new element methods?</font></table>
<br>
<br>
<br><font size=2 face="Courier New">At 10:07 AM -0400 7/15/03, William Krick wrote:<br>
>I was wondering if it might be useful to add some methods to Element...<br>
><br>
> getInt(java.lang.String name)<br>
><br>
> getFloat(java.lang.String name)<br>
><br>
> getBoolean(java.lang.String name)<br>
><br>
> getString(java.lang.String name)<br>
><br>
<br>
Such methods did make it into one of the betas a couple of years ago. <br>
They were eventually removed on the grounds that there were just too <br>
many methods in the class. While every such method seems plausible <br>
and useful when considered in isolation, adding every convenience <br>
methods requested rapidly grows the class to the point of <br>
illegibility.<br>
<br>
API size has a huge cost to ease of use, and there's a point at which <br>
it begins to grow exponentially. The first five or six methods are <br>
effectively free. The next five or six are worth the cost. Beyond <br>
that the cost starts skyrocketing, and it gets much worse with each <br>
batch of methods you add. 40 public members is really the effective <br>
outer limit of a good class. Beyond that it's time to start asking if <br>
you can refactor into more smaller classes. Element is already quite <br>
large. It really can't handle the weight of a whole new batch of <br>
convenience methods.<br>
-- <br>
<br>
Elliotte Rusty Harold<br>
elharo@metalab.unc.edu<br>
Processing XML with Java (Addison-Wesley, 2002)<br>
http://www.cafeconleche.org/books/xmljava<br>
http://www.amazon.com/exec/obidos/ISBN%3D0201771861/cafeaulaitA<br>
_______________________________________________<br>
To control your jdom-interest membership:<br>
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com<br>
</font>
<br>
<br>