Re: variable length fields for flexibility in subroutines



"LX-i" <lxi0007@xxxxxxxxxxxx> wrote in message
news:Gr6dnQRo2Y4ZUjvbnZ2dnUVZ_u6rnZ2d@xxxxxxxxxxxxxx
Pete Dashwood wrote:
An alternative I considered (and discarded) was to have an array with the
offset and length of every field, then dynamically build a SUBSTRING
statement every time I needed to access a field. This seemed too
unwieldy. The solution below gets compiled into a .DLL and so the source
code is not visible in any applications that use the interface; they just
have a reference to the Assembly. (Another example of Source code being
unimportant... :-))

What you might look into is creating a description of your "interface
block" in XML, then parsing that document and spinning through the nodes
to build your interface block. You'd still have to modify (or extend) the
class if you added a new property, but you could have a generic "Generate
Block" getter that assembled it according to the specs in the file.

Something like...

<interface_block size="8192">
<parameter name="street" position="1" size="150" />
<parameter name="city" position="2" size="50" />
...
</interface_block>

(The position attribute is just so you can retrieve them in the right
order, even if they're not in the right order in the XML file.) Judging
from the way you've talked about your components, having a reusable
configuration for interface blocks might be nice.

I have a "reusable configuration" for interface blocks; I just instantiate
an instance whenever I need one :-)

(I take your point that if the interfaces change, it might be useful to have
a flexible means of implementing them. I am addressing this through a
generator. The generator certainly COULD produce XML, but I have decided
against doing this for the reasons outlined below. Instead, it will produce
a C# Class, that is immediately built into a .DLL and loaded into the Global
Assembly Cache.)

I gave this some thought and here's what I think:

1. There is a (big?) difference between global parameters that remember
system state, and local parameters that are part of program interfacing.
2. While it is possible to implement both using XML, I don't believe it is
desirable.

The use of interface objects as provided through a .DLL is much better for
interprogram communication. It is secure, and managed entirely by the
entities concerned with its content. No possibility of any external
meddling...no XML processing overheads... enjoys the benefits of private
and/or protected status... and can only be accessed through a single
interface (GET,SET).

So for "run time" parameters passed between programs, this gets my vote.

If there are changes to an Interface Class (like the one I posted), I would
make those changes and rebuild the .DLL. This has minimum impact on the
existing system (no recompilation of any Assemblies), is efficient, and
secure. While XML could do the same job, it could be subject to external
manipulation. These days, the overhead in using XML is negligible (and you
could load the structure during initialization), but you still have
something that is readable (and accessible) by Humans, when it is intended
for program consumption only. Manipulating XML dynamically, can be a bit
unwieldy as well.

However, XML is an incredibly powerful tool. The DotNET FCL has
comprehensive facilities for managing it easily and I have already found it
to be useful for remembering things like user options and system state. In
some instances, where the overhead of a RDB is hardly warranted, XML serves
better.

I think the way I'm going is:

1. Anything that could be of interest to a human ("last used", global
options and settings, read-only datasets where a RDB is simply overkill...)
use XML

2. Interface blocks for inter-program communication...Create an Interface
Class and instantiate an object of it.

Thanks for your post and ideas, Daniel.

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: developing for something that isnt there..
    ... xml was chosen becouse well. ... creating a tree model of javabeans was my insisting becouse i didnt' ... had a complelty differnt strucutre and style of interface, ... and interface to send messages about them the classes ...
    (comp.lang.java.programmer)
  • Re: problems typecast,find by function/member name and getting "managed reference"
    ... and then call methods in the interface. ... and add info about it in XML resource list file and designers who via ... *compiler* more information, which clearly isn't relevant at runtime. ... Casting is not relevant if some datais unmodified(in ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: developing for something that isnt there..
    ... i've been taksed to create a framework that would read a complex xml ... problem that java bean tree has not been built yet. ... i do have a concept of what to pull from the xml, ... and interface to send messages about them the classes ...
    (comp.lang.java.programmer)
  • Re: Converting a number of objects to XML, HTML or Excel
    ... > writing their contents either to XML, ... > that I need to keep something that understands the related objects ... > ClassA also contains a single ClassD, do I create an interface were I ... string ToXml(); ...
    (comp.object)
  • Re: interface blocks
    ... > I have about 3500 subroutines with 400,000 lines of f66/f77 that I ... INTERFACE blocks are usually not checked against the ... So, the compiler should provide ... As for the other supposed problems with INTERFACE blocks: ...
    (comp.lang.fortran)