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.
So far you didn't bring up a *single* reason for your design, yet you expect people to help you. 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. 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. 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. 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. When you use storage for your new system, persist the data in a better way and don't use a fixed-width text file, unless that is the *actual* need. I can only think of a few reasons for this, otherwise you should use a database to save data, either a local one or a server. I can hardly imagine a single valid reason (except hardware handlers) where you'd need to have a padded in-memory representation of *any* read/write property value. What happens to the data when your client wants to change the max length of FirstName? Do you update all your code? What happens if you forget to update just a single place and it makes into production? Do you go back to your storage and update all the data to match the new length? What kind of client is that where you can do that to production data just like that? If you're reworking an old system you might as well do it right. Trying to imitate COBOL behavior is certainly wrong in any object-oriented language, Java and C++ included. HTH, Gyorgy Bozoki > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Jon > Rothlander > Sent: Wednesday, November 15, 2006 09:19 > To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM > Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net? > > If .Net cannot deliver, then Java can. IBM has had the Java > tools available to port the code for years now. The clients > will choose that solution if they have to, but they would > rather go with a .Net solution if possible. > > What about this? If COBOL can do this, then it creates > iLCode that does this and works. That iLCode is the same > iLCode that VB and C# outputs. So whatever solution COBOL is > using to create the data structure, why can I not do the same > thing in VB or C#? Why would I have to write it in COBOL if > in the end it's just all iLCode anyway? Maybe I'll download > COBOL for .Net and decompile some of the code to see how they > accomplish this. My guess is that they are using some unsafe code. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
