HSSFCell short/int

[David Law <da...@apconsult.de>]

Could it be, the HSSFCell getCell(short cellnum)
method has been rather confusingly deprecated?

Arguably, its laudable to "avoid sign extension",
but as there can only be 256 columns anyway,
I find it really rather misleading.

Regards,
DaveLaw

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org

Re: HSSFCell short/int

[Josh Micich <jo...@gmail.com>]

Hello Dave,

It's not clear if you are questioning the merit of creating the newer
method "getCell(int)", or whether the old method "getCell(short)"
should have been deprecated at all, so I'll attempt to answer both
concerns.


The most visible reason why POI is moving away from bytes and shorts
is the need for typecasts when using literal integer constants, even
when the value is quite obviously within range.  For example without
the new method "row.getCell(5)" would not compile.  We would have to
write "row.getCell((short)5)".

There have been several POI bugs involving representation of unsigned
(ushort, ubyte) quantities with java datatypes (signed) of the same
width (short, byte).  When shorts and bytes are used, the corrected
code generally needs more typecasts and bit mask expressions.   If
those datatypes are changed to int, the code is usually simpler and
easier to read.

The new method "getCell(int) method may in the first place have been
introduced as a result of the XSSF common interface work (a separate
reason, as suggested by Mark B).


That sort-of explains the rationale for creating the new method
"getCell(int)".   The reason for deprecating the old is to eliminate
overloading (of "getCell").  Method overloading is sometimes very
handy but has quite a few pitfalls, and for that reason POI tries to
use overloading sparingly.

As far as the exact meaning of the '@deprecated' tag, in POI (unlike
in the java runtime library) it means "This method will be removed in
a future POI version".  An alternative is always given.  A deprecation
date has been provided in most places, to help POI users prioritize
clean-up of their own code.


You mentioned the comment from the the first line of the deprecated method:
        int ushortCellNum = cellnum & 0x0000FFFF; // avoid sign extension
The bit-mask is correct for 16-bit unsigned conversion.  Masking with
0xFF would be wrong because it would silently convert every possible
input to a valid column index.  For example: is it sensible for
"getCell((short)300)" to succeed?   Maybe it looks pointless to
convert values in the range (-32768...-1) to (32768...65535) is
because the maximum column index is 255.  This conversion to unsigned
16-bit has been done because it's more likely that the caller intends
an unsigned quantity (column indexes are never negative).  So if a
negative value *does* get into this method, it's probably better to
format the error message in terms of the unsigned 16 bit quantity.
Similar results could have been achieved with bounds checking the
argument, but would involve duplicating all the MissingCellPolicy
logic too.
So - that line of code is there for making better error messages, and
has little to do with the reasons for the  deprecation.

regards,
Josh

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org

Re: HSSFCell short/int

[MSB <ma...@tiscali.co.uk>]

I am only guessing David but the change my be the result of introducing the
SS model to accomodate both the binary and OpenXML based file formats
'invisibly'. If you look at the org.apache.poi.ss.usermodel package, you
will find there are classes called Workbook, Sheet, Cell, etc and these are
used by those who may have to work with both types of file format and do not
want to maintain two different code bases. Well, both HSSFCell and XSSFCell
both implement the Cell interface and I would guess that the decision was
taken to include just the single method getCell(int) in the interface and -
as a result - both concrete classes because the OpenXML file format does not
impose the 256 row limit on the user.

As I said, this is only a guess.

Yours

Mark B


David Law-2 wrote:
> 
> Could it be, the HSSFCell getCell(short cellnum)
> method has been rather confusingly deprecated?
> 
> Arguably, its laudable to "avoid sign extension",
> but as there can only be 256 columns anyway,
> I find it really rather misleading.
> 
> Regards,
> DaveLaw
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
> For additional commands, e-mail: user-help@poi.apache.org
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/HSSFCell-short-int-tp26607785p26612088.html
Sent from the POI - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org