OO conventions

[Steven D'Aprano]

On Thu, 02 Feb 2006 17:00:26 -0800, Blair P. Houghton wrote:

> Image would be a superclass to JPGImage, BMPImage, PNGImage, etc...
> 
> But which to use could only be determined AFTER opening the file,
> because "file.jpg" doesn't have type JPG, it has type string and
> semantic value "maybe a jpeg file or maybe something misnamed as a jpeg
> file".

Absolutely.
 
> So Image.open(filename) seems right as a factory function that opens
> the file, figures out what it really is, constructs the appropriate
> subclass object (likely by passing a string to the constructor, e.g.,
> JPGImage(filename)), and returns the object via the superclass type.
> The caller can then either check a flag in the superclass to see what
> type the subclass is, or just assume it's the right type of image for
> the filename extension (or does Python have RTTI? I don't recall if
> I've seen it, yet...).

RTTI = Run Time Type Information, yes?

Objects in Python are strongly typed, if that's what you mean. So if each
image kind (jpeg, tiff, png, etc.) is a subclass, then you can easily use
introspection to find out which subclass it is.



> Though if the filename doesn't match the content, someone should raise
> an exception...

That depends on whether you believe DOS style filename extensions are
significant, or that they are a poor substitute for real metadata.

If you come from Windows land, you might thing the file extension is the
file type. If you come from Linux land, you might think that file
extensions are just a label stuck on the file name as a convenience for
the user. If you come from Macintosh land, especially pre-OS X, you
probably think that file extensions are at best a useful redundancy and at
worst an abomination.

>From a UI perspective, an application should never refuse to handle a file
because of a mismatch between the file type contents, the file type
metadata (if any), and the file extension, with one important proviso as
follows. In general, if your application handles (say) both JPEGs and
GIFs, and the user tries to open a JPEG named foo.gif, then the correct
action is to advise the user that the file is actually a JPEG, and
give them the opportunity to open the file anyway.

Whether that is best handed internally by making Image.read() raise an
exception or not is a question for the class designer.

The proviso is, if there are potential security implications of that
mismatch (e.g. an executable file masquerading as a .text file), and the
target audience is technically naive, then I believe it may be appropriate
for the application to refuse to handle the file. Don't let the user shoot
themselves in the foot if they aren't technically sophisticated enough to
realise they are shooting themselves in the foot.


-- 
Steven.