> >>The solution proposed is simply silly when you look at the 3Gl's today.
>
> So how would you solve it? It's easy to say that the solution is silly if
> you cannot offer a non-silly solution.
I provided a solution for the full name = firstname + lastname problem,
as have others, as that's what the available
information said. Below you describe more in detail the scenario, which is
familiar to me, so a better solution is at hand.
Your solution is 'silly' when you look at how 3GL's work, as you want
to bend the 3GL's nature to a way of working with data
that's not suitable for a 3gl and also unnecessary. Just because an AS/400 uses
files with positioned fields doesn't mean you've to
use that format in your own OO code.
> >> people shouldn't focus on how to implement a bad solution because
> >>it's apparently hard to implement
>
> So what exactly is hard to implement in regards to a class with properties,
> which handles this easily? Sounds pretty simple to me and I've been doing
> that for the past year or so. I have not found anyone that struggle with
> that solution.
The problem is with the 'the value for 'Firstname' starts at pos 20 in
the value of full name'-restriction (and other
similar restrictions). that's hard to do, as you've to use different string
mechanisms than which are build in the platform, i.e.:
you can't use a char* pointer inside a charbuffer which is the fullname.
> My goal in posting this question was to see if .Net had some way to support
> multiple variables pointing to the same set of memory. That's sounds like a
> reasonable thing to me. If it did support that, it would save me the time
> of having to construct these data structure classes.
it doesn't do that, so you can forget that requirement. Now, what I
wonder is: why do you need this requirement? And I mean:
INSIDE your OO code. Not with communications with other systems, but within
your code: why do you need this requirement? IMHO you
would never run into this, or better: you can write normal code which does the
same thing, as shown by some like concatenating first
and last name to fullname and be done with it, and your OO code would work
normally.
The problem is then mitigated to communications with external systems,
like import/export files with fixed-width, positional
data.
I call these import/export files, as they're used to export data from
for example as/400 into another system, inserting the
data into a db there, use it from that db in the application and export data
back in the same format for the as/400.
> So what solution do you suggest?
>
> In .Net if we want to write code out to an ASCII formatted flat file to be
> loaded into another system, how would you accomplish this if the flat file's
> character data is positional? Like my first example which listed something
> like...
>
> "First Name Middle Name Last Name "
that's not hard. You can write any string you'd like to the output,
using a piece of code which writes first name, middle
name and last name at given positions into a file. That's so basic you can
generalize this to a great extend, using conversion
tables for example.
This is for communication with an external system, not for your .NET
code internally. What you explained however looked like
you wanted to use a string like the one above in your .NET code as
'myObject.FullName', which IMHO is not necessary, because the
format is ONLY required for a given export file.
> Someone in a previous post asked why anyone would want to do this. Well,
> that is the data I am given. I don't think I can convenience all of the
> applications that interface with application that I am porting to .Net, to
> go in and rewrite all of their systems to support my need that the data not
> be in this format. I have to handle what I am given. The client's question
> would be to ask why .Net cannot handle this common and very simple data
> format.
of course .net can handle that, though that's pure import/export: so
importer reads data from file, converts data into db
inserts so the .net code can use it, exporter does the other way around.
WHY else import the data? You planned to use flat file ascii files as
your live database at runtime?
> In .Net without any structure to handle this, such as the class/property
> examples in previous emails, you cannot do something like...
>
> String FirstName = "First Name"
> String MiddleName = "Middle Name"
> String LastName = "Last Name"
> String FullName = ""
>
> FullName = FirstName + MiddleName + LastName
>
> That will not work. You'd end up with...
>
> "First Name Middle Name Last Name"
>
> That's not valid for the ASCII formatted-positional file format. So you'd
> have to go in and add a buffer function to adjust the number of trailing
> spaces. At that point, what's the point! Why not just use the
> class/property solution, which you say is silly. Doesn't sound nearly as
> silly as going through all of this extra work to get the ASCII formatted
> file that you need.
I marked the fullname with char* inside that same charbuffer with 0's
inserted at startpos-1 silly and I stick with that
because it's useless to use that in-memory in your OO code.
You only need these string in your export/import ascii files so you
simply need to write an import/export tool, IF you want
to work with flat ascii files, which is something I also find rather odd these
days, with a wide range of solutions to get inter-db
communications and almost every db on the planet having good access providers
for a wide range of development platforms. I mean, if
you can use an os/390 hosted db2 db in full from C#, why not your db as well?
But ok, sometimes you need to import these files because they're
created by hardware devices or stone-age software. However,
it still means these files are temporary and need to be imported into the final
storage, from which your software reads the data to
process/work with it. That software doesn't need that full name property.
> Then going the other way, you'd have to read in the data using positional
> string manipulation such as MID(). That's allot of extra code to add to
> support something as simple as reading positional character data.
Of course you don't have to do that. You can create a generic file
reader which accepts a table with startpositions, lengths
and property names. then you create a factory to produce objects to read the
data into and with the startpositions and lengths you
can read data from the file into the property with the name specified, using a
simple routine which converts a set of chars from a
line read from the file into a new string. that's it.
After the file is read, it can be destroyed, the data is in the app and
should be persisted into a more appropriate storage,
like a db.
> Oh. Maybe you mean that .Net applications shouldn't interop with legacy
> systems that are not Xml compatible or systems that are using non-SQL
> database such as DB2... which would include most hotel systems, most
> insurance companies, banks, and most systems written pre-2000. Or should we
> force all of these systems to upgrade to web services, xml, or sql server so
> we .Net developers do not have to work around issues like this.
I hate xml so I wouldn't suggest that as more appropriate. About 5
years ago I've written a C++ importer/exporter for an
AS/400 box, flat file positional ascii files and sqlserver where the
importer/exporter had to do conversion of the data as well like
values in rows suggested add/remove etc. It's very easy to do, and if you do it
correctly, it's not a lot of code as well and
flexible to setup as well, because you use a table so if positions change you
just need to update a table.
Still it's unmaintainable and fragile as the chain of files/importers
etc. is always a weak structure. Often it's more
efficient to simply let the application directly communicate with the sourcedb.
> By the way, most of these systems are running modern (not dinosaur) systems.
> IBM is running commercials right now trying to sell these systems... with a
> new and more modern name. Most of these systems are running Windows as
> well. So the clients that I am working with want to port the legacy systems
> into the Windows partition and work with .Net going forward. However, right
> now the best solutions port to a Java partition and run them in WebSphere.
> IBM seems to have a pretty big service for this, so apparently they don't
> think it's silly to find a solution for this.
Every 'solution' which is based on the same old crappy 'visions' of how
communication between different systems should take
place, namely ascii files dumped in a folder which is polled is IMHO not a good
solution, as it's redoing what was already there
without any progress, as the PROBLEMS of these old 'visions' are still present
in the 'new' software so the people who pay the big
bill won't get any value for their money.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
