Re: Could this be done?
D. Newhall wrote:
>
> DB James wrote:
>
> > I don't quite follow this. I would understand and agree that it would be
> > useful with
> > image files to be able to translate every other type to, say, BMP format,
> > and from
> > there to other types. This would reduce the number of translations. Does
> > the same
> > idea apply to other types of extractions or conversions?
>
> What I meant was that when loaded by the program all files would be the same
> internally.
> For example, it would read a .DOC file converting it to an intermediate format
> inside
> the program. Then the ASCII text converter takes the intermediate format and
> returns
> the .TXT file.
>
> To get around the .BMP to .TXT problem you could have different classes of
> files and
> you can only convert filetypes that are in the same class (for the most part).
> For
> example, JPEGs, bitmaps, PNGs, etc. are all classified as type Image and can
> be converted
> to and from one another; ASCII text files, .DOC files, RichText files, etc.
> would be
> of type TextDocument or something. This is needed because you can't convert a
> Bitmap
> to a text file (although vice-versa could be done) so the converters need a
> way to
> check for limitations but without sacrificing flexibility.
>
>
> > Perhaps you could elaborate on this. I was imagining a limited conformity
> > with the
> > needs of the shell program that would be explicit and be followed by the
> > authors of
> > the includes. For example, there might be rigidly formatted comments in the
> > include
> > that would be readable by the shell to establish what capability the include
> > offers.
> > Perhaps the only call would have the same name as the name of the include:
> > text2html.e,
> > so the call would be text2html(fullPath)or text2html(lines) or whatever.
>
> Here's an example of a possible API:
>
> }}}
<eucode>
> -- Include API functions and constants
> include vertex.e
>
>
> integer converter_rid, -- The routine ID number for the converter function
> extractor_rid -- The routine ID number for the extractor function
>
> -- This is the actual extractor function.
> -- It takes the file number for the opened file to extract the info from.
> function txt_extractor(integer file)
> object line
> line = gets(file)
> while sequence(line) do
>
> -- This goes through every line and converts the plain ASCII
> -- text to an intermediary format for text.
>
> line = gets(file)
> end while
> end function
>
> extractor_rid = routine_id("txt_extractor")
>
>
> -- This is the actual converter function.
> -- It takes the file number for the opened file to convert the info from
> -- the intermeiary format to the new one.
> function txt_converter(integer file)
> object converted_data
> -- Loop through internal text data
> for i=1 to length(text_data) do
>
> -- Take the internal representation for text and convert it to the new
> -- format storing it in converted_data
>
> puts(file, converted_data)
> end for
> end function
>
> converter_rid = routine_id("txt_converter")
>
>
> -- Holds the ID for the .TXT file type
> integer text_file_id
>
> -- This declares the type of files that it can work on
> -- Arguments are: extension, description, file class
> text_file_id = declare_filetype(".txt", "ASCII text file", CLASS_TEXTDOC)
> declare_convert(text_file_id, converter_rid)
> declare_extract(text_file_id, extractor_rid)
>
>
> <font color="#330033"></eucode>
{{{
</font>
>
>
> The Euphoria Standard Library project :
> <a href="http://esl.sourceforge.net/">http://esl.sourceforge.net/</a>
> The Euphoria Standard Library mailing list :
> <a
> href="https://lists.sourceforge.net/lists/listinfo/esl-discussion">https://lists.sourceforge.net/lists/listinfo/esl-discussion</a>
>
Hello,
With a beginning like that I'm guessing it would not take as much of your time
to write the program as you think. If you do it, I hope I'd be able to add a
module or two.
A question though, whether it is useful or not, is this: is it really necessary
to assume the main program must create an intermediate version of whatever the
original file contains? If that assumption were dropped, then the implementing
would be much easier, as far as the "shell" program is concerned. It could be,
in effect, ignorant of the functionalities that the include files offered. It
would not have to know how to handle the many different types of files that it
would be called upon to deal with.
If it were decided that some intermediate capability is necessary, such as that
which you describe, or with image-files-to-BMP or whatever, then some clever
programmer could write intermed1.e. Another could write intermed2.e, etc. and
then the convert or extract functions would refer to those "standard" functions
before doing their thing. At no time (ideally) would the shell program have a
clue about any of this.
And, to repeat a previous point, it seems to me that a project like David Gay's
new tutorial could be done this way. Consider all the different topics that such
a tutorial series might contain: language-specific items, OS difference-items,
graphics, sound, GUI, database, HTML, and on and on. Wouldn't it by much easier,
and faster, if many brains worked on areas they are interested in? One big
advantage would be the lack of a need to coordinate the programming, beyond a
minimal level. If two people tackled the same topic, what harm would that give?
--Quark
--Quark
|
Not Categorized, Please Help
|
|
