>>I'm sorry for saying this, but you seem to miss what everyone was trying >>to tell you in the past 15+ messages: you *can* do what you want in C#. >>But just because you can do it, it doesn't mean that you should.
I'm not missing what everyone is saying. I'm trying to make sure everyone understand the issues at hand and why I am trying so hard to work around it. >>So far you didn't bring up a *single* reason for your design, yet you >>expect people to help you. I have. I just don't want to send 3,000 lines of legacy code to show you how it works. I have tried to come up with very small samples sets to show you what I'm looking at. Only one or two posts have directly referenced possible ways to solve the problem. The others suggested not taking on the problem or changing languages. Here's another example... DATE Start(1) Length(8) YEAR Start(1) Length(4) MONTH Start(5) Length(2) DAY Start(7) Length(2) Looking at this one system that I can port about 90% or more to .Net as of today. This sort of code exists in over 1,000 programs that contain anywhere from 500 to 5,000 or more lines of code. It does exist in utility programs that are called, but some sort of code like this exists in nearly 100% of the programs. Most of the programs have 3 or 4 data structures like this set up. >>I'm going to be the bad guy and tell you this (what everyone tried >>so far, but in a more polite way): your design is *wrong*, it'll >>have all kinds of problems down the road, even in the near future. Well, yeah. That's what I said in my first posting. That was the whole point of starting this thread. I know it's not the best option and I'm trying to find a way around it. I'm sure that we are on the same page in regards to problems down the road. Maybe that's a good topic of discussion because I don't see it so I'm probably missing something hee. >>That is *not* how you implement properties in an object-oriented language. >>What you try to accomplish is an old approach to storing properties, and >>is (fortunately) outdated. You should not even try to do it, period. Not >>in COBOL.Net or whatever, not in C#, etc. It is not a question of .Net >>being able to do it: you can abuse C# to do practically anything. The problem here is that all of the code is pushing to FullName (DATE in the above sample). That's really kind of the whole point these structures are used in the legacy systems. So all of that code would have to be rewritten if we made the FullName/Date readyonly. The whole goal here is to find a way to get all of the code working without having to rewrite it all. Once it's functional, we can go back and make these changes as we have time and as we go forward. We just want the application to work first, then we can performance tune and remove issues like this. >>If you want to have an object with a FirstName and LastName attribute, >>create and object like that, with two private string members and two >>public properties. If you then need a FullName property, create a new >>readonly property and return the concatenation of the two former; do *not* >>use any padding in your object. Ok. I see what you are saying here. What you have a problem with is pushing to fullname and have it divided into the other properties. Is that the main concern here? Well, that and the padding. >>When you're ready to persist your object to a legacy system, *only then* >>use padding, but not in your object; implement a converter object for this >>purpose that is capable of taking an instance of your object and spit out >>a stream or a big string that contains padded data. Pass this to another >>object or function to actually persist it to a file. I'm working on implementing this approach where the data is not using any padding. That MAY be possible. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
