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
