Thanks Cosmin,
Firstly, thank you for both your thorough response and your incisive
sense of humor, which even helps digestion of the solutions you offer in
ways that make them even more useful. Secondly, the ordering of your
solutions from most encapsulated to most exposed build-your-own
meta-language with a parser culminating in the very advice I am trying to
avoid shows and evaluates for me a spectrum of ready solutions. This all
makes me see how high performance oriented Fortran 9x really is and how
expensive a trade-off are built in graphics, RAD GUI development (even the
best in the programming industry), and a very familiar, quite complete, and
powerful implementation of object-oriented programming for language features
that are tuned to the decades old and still unchanging needs of scientific
computing: high-volume, highly-structured data throughput in a
computationally-intensive environment.
Plug-and-play reusability is, pardon the expression, a gimmick, which I
have learning to sell myself on and have found very useful in not
re-inventing the computer science wheel every time I need to do something
that involves creating and parsing little variable-centric languages such as
are instantly handled by Fortran 9x NAMELIST-directed I/O. I would like to
used Delphi as a transparent
Del-tran making the best use of the best parts of both languages. I realize
that as the thread started by Robert Meek on the topic of deleting an
element from an array brings home once again that the tax of encapsulating
programming language dynamics in high-level facilities is paid at run-time
in seemingly unaccountable ways. For plug-and-play re-usability of modern
computer science routines to be feasible, it must become such that the
solutions it encapsulates perform to between 60% and 80% of optimal runtime
efficiency, i.e., the best hand-coding possible, in any conceivable context
of application . I guess the over-head debate almost as old as Simula 67 or
at least as old as C++, but I'm sure the promise of OO and of Delphi's OO
successor, component orientation, can and will be realize in high run-time
performance, plug-and-play re-usable components that are mini-applications
in themselves that needn't be re-coded (almost) at all: functionality pills
to boost the potency of modern applications.
Specifically, I envision the system to work according to (excuse the
schematic and informal syntax):
namelist_type_inst.write(varname,[var_type],varfile,[permissions]);
and
namelist_type_inst.write(varname,[var_type],varfile,[permissions]);
This way I have an instance of a NAMELIST class which encapsulates write and
read methods. The read method should read from a delimited plain text file,
tokenize it, and parse it for regular expressions defined by the variable(s)
and their types given as parameters. If there is a way to infer a variable's
type from its instance properties, then the additional type parameter is
unnecessary. If however, this problem turns out to be recursively
unsolvable, then additional type information must be included as a parameter
to the read method.
I could say more and I should provide an example, but that's for another
note.
Paule
----- Original Message -----
From: "Cosmin Prund" <[EMAIL PROTECTED]>
To: "'Borland's Delphi Discussion List'" <[email protected]>
Sent: Thursday, March 09, 2006 4:16 PM
Subject: RE: A Delphi Component that enables namelist-directed I/O
> Delphi has a VERY re-usable, plug-and-play solution for handling
> object-to-text and text-to-object conversions. It's named "Delphi
> Streaming
> System" and it's the thing that produces the DFM's; And you will not like
> it
> - it's not really human readable.
>
> Also there's Delphi's TStringList. It has a "Values" property that can be
> used to handle basic "key=value" pairs. Not very smart but can do the job.
>
> If TStringList's basic "key=value" is not enough you may consider
> TIniFile.
> TIniFiles offers a bit more, specifically it offeres a way to read a
> "value"
> as a given native type. It also has support for grouping values into
> "sections".
>
> If you need more structure there's XML. It is text, it is cool and it is
> almost human readable.
>
> If you don't want DFM, you don't want TStringList, you don't like good-old
> TIniFile and you think XML is overkill, you can always roll your own :-)
>
> How exactly do you envision this plug-and-play system to work?
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Paule Ecimovic
>> Sent: Thursday, March 09, 2006 11:57 AM
>> To: Borland's Delphi Discussion List
>> Subject: A Delphi Component that enables namelist-directed I/O
>>
>> Hi, All
>>
>> After coming across very useful threads in this list on writing to
>> and
>> reading from human-readable text files in structured ways, such as
>> writing
>> the values of a list of variables of various types to a file containing a
>> string representing a given variable's name followed by a delimiter
>> followed by that variable's value along with the ability to extract the
>> information back from the corresponding file, I came to wondering whether
>> there is a Delphi component that does this. In the past when I have
>> posted
>> to this list about this I got very useful pointers outside of Delphi,
>> i.e., a wrapper of a C routine for NAMELIST-like functionality, or the
>> tried and true yet insufficiently re-useable maxim "For best results,
>> advice roll-your-own". I am wondering about a plug-and-play standard
>> Delphi solution to this problem that I can re-use at the drop of a hat,
>> everywhere.
>>
>> Many thanks in advance,
>>
>> Paule
>> _______________________________________________
>> Delphi mailing list -> [email protected]
>> http://www.elists.org/mailman/listinfo/delphi
>
> _______________________________________________
> Delphi mailing list -> [email protected]
> http://www.elists.org/mailman/listinfo/delphi
>
_______________________________________________
Delphi mailing list -> [email protected]
http://www.elists.org/mailman/listinfo/delphi
