The first thing I'd need to know is how to refer, in a standard Pascal or Delphi way, to the source-code-level name of a variable so as to put it in a list. Then assemble a list of variables of various types. Then assign a name to the resulting list, which would also be a variable of (class) type NAMELIST. This class would contain methods for inputing and outputing values of variable in an instantiated NAMELIST object at runtime.
Paule ----- Original Message ----- From: "Cosmin Prund" <[EMAIL PROTECTED]> To: "'Borland's Delphi Discussion List'" <[email protected]> Sent: Friday, March 10, 2006 10:11 AM Subject: RE: A Delphi Component that enables namelist-directed I/O > Can you post a short "demo" of what you're trying to accomplish, using > Pascal/Delphi syntax? I insist on pascal syntax (as opposed to pseudocode > or > fortran) because I think you want something that can't be accomplished by > a > compiled language without using some odd trick. > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Paule Ecimovic >> Sent: Friday, March 10, 2006 1:24 AM >> To: Borland's Delphi Discussion List >> Subject: Re: A Delphi Component that enables namelist-directed I/O >> >> 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 > > _______________________________________________ > Delphi mailing list -> [email protected] > http://www.elists.org/mailman/listinfo/delphi > _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
