>>What the nice people here are trying to do is help you, by saying that
>>it's a stupid idea. Today there are better ways to do what you want.
Yeah ok. It's a stupid idea. But how do you suggest doing it correctly?
At the bottom of this post is a simple real-life example. How would you go
about supporting the required needs?
>>2. .NET programmes DO NOT understand COBOL, and thus they can't maintain
>>your solution of COBOL-style C# (or Java). To do that, you will need to
>>find guys that have an astounding sense of humor, as well as know both
>>COBOL and .NET. Expensive.
That's why I do not want to port it to COBOL for .Net. No one wants it or
understands it.
Anyone that understands .Net can certainly understand a class with
properties and string manipulation. Regardless of how stupid the idea is.
It is simple and easy to follow and understand.
>>3. It doesn't sound as if you have lots of OO experiece, so I suggest that
>>you read up on the subject. Write your first few classes. You will realize
>>what these posts mean.
Even if I was the guru of OO, it wouldn't matter here. I am not trying to
be an OO purist and I don't think it's OO or nothing. I'm trying to make
the thing work. I do not use OO as the one and only standard and anything
that violates... gets thrown out. If an OO solution isn't there, then I will
certainly do something else.
If everyone here is say there is another way... then what is that way? I
don't need details, just the basic idea. If there is a better way that
doesn't require rewriting from scratch, then I am all ears. If the only
option is... COBOL or start from scratch, then that's not a real option.
By the way, I've been working with .Net since before the first beta, writing
code full time since I was 18 (1991) and I've been working in R&D since 2001
developing .Net compilers. So experience isn't the issue. Porting the code
in away that will allow me to not have to rewrite it is the issue. OO
aside, the thing just has to work. If the solution violates someone's OO
standards, well that's ok with me.
****************************************************************************
THE EXAMPLE
****************************************************************************
Here's a real life example that I modified to fit the FullName sample from
previous posts...
The original code was ported into VB.Net, so the code below is VB. I
modified it to remove the code not needed to show how it works, then I
modified it to work with our FullName example using a class with properties
to give the effect of a data structure.
If there is a better way, please let me know. For me, I do not see it. So
my question is simple. How would you suggest this be accomplished without
using a SET() on the FullName?
By the way, you cannot muck around with the data. It's running on a legacy
system, the data is real time, and I cannot mess up the data for the
existing legacy system. So any ideas of throwing out the database and
moving into all into SQL will not work in this example. In other situations
it would, but not this one.
Also, the FullName field has three possible formats based on the length. In
the real application, the data has nothing to do with names or anything. I
am just representing the basic idea with data that makes logical sense. The
real fields are 80, 100, and I think 120 in length. Depending on the
length, the legacy applications load the data into a given data structure
and take it apart accordingly. The rest of the code works the same
regardless because they are all referencing the same field names or
fullname, firstname, and lastname.
The solution I came up with was the only solution that would let the
original code process the data without have to rewrite all of the original
code... which is the whole idea here. If I wanted to just rewrite the
million lines of code, I would be doing that. The whole point is to port
the code in a way that will allow it to run in .Net. Then go back and make
changes as needed for performance tuning and enhancements. If you have to
touch the code at that point, then you can work to rewrite it as needed and
get ride of the stupid stuff that everyone has an issue with.
What's a good way to handle this that you would consider not to be stupid?
In the end, the solution here works, is easy to understand, easy to
maintain, and easy to port from the original legacy code. It may violate
some OO standards, but that's the least of my worries here. I'm more
concerned about it actually working and having the performance that we need.
It does.
I set this sample up in a vb.net winForm test app. I created a form1 with a
button and two textboxes. I create a class1 to contain the interface,
properties, etc.
If anyone has some suggestions as far as a better way to handle this, I am
all ears and I very much appreciate people's time to post replies to this
thread. I just need to understand why people have a problem with it and how
to fix it. Even knowing that this whole idea is stupid doesn't help me
solve the problem at hand.
Best regards,
Jon
Public Class Form1
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
'Read the data in from the database field. This just simulates that
there are three different formats possible
'in the database.
'Dim strSample As String = "Jon Rothlander"
'Dim strSample As String = "Jon Rothlander
"
Dim strSample As String = "Jon Rothlander
"
Dim obj As Object = New Class1.FormatType
Select Case strSample.Length
Case 20
obj = New Class1.FullName_20
Case 40
obj = New Class1.FullName_40
Case 60
obj = New Class1.FullName_60
End Select
obj.FullName = strSample
Me.TextBox1.Text = obj.FirstName
Me.TextBox2.Text = obj.LastName
End Sub
End Class
Public Class Class1
Public Enum FormatType
FormatType_20
FormatType_40
FormatType_60
End Enum
Public Interface Name
Property FullName() As String
ReadOnly Property FirstName() As String
ReadOnly Property LastName() As String
End Interface
Class FullName_20
Implements Name
Private _Line As Char() = New Char(20) {}
Public Property FullName() As String Implements Name.FullName
Get
Return Mid(_Line, 1, 20)
End Get
Set(ByVal value As String)
_Line = value
End Set
End Property
Public ReadOnly Property FirstName() As String Implements
Name.FirstName
Get
Return Mid(_Line, 1, 10)
End Get
End Property
Public ReadOnly Property LastName() As String Implements
Name.LastName
Get
Return Mid(_Line, 11, 10)
End Get
End Property
End Class
Class FullName_40
Implements Name
Private _Line As Char() = New Char(40) {}
Public Property FullName() As String Implements Name.FullName
Get
Return Mid(_Line, 1, 40)
End Get
Set(ByVal value As String)
_Line = value
End Set
End Property
Public ReadOnly Property FirstName() As String Implements
Name.FirstName
Get
Return Mid(_Line, 1, 20)
End Get
End Property
Public ReadOnly Property LastName() As String Implements
Name.LastName
Get
Return Mid(_Line, 21, 20)
End Get
End Property
End Class
Class FullName_60
Implements Name
Private _Line As Char() = New Char(60) {}
Public Property FullName() As String Implements Name.FullName
Get
Return Mid(_Line, 1, 60)
End Get
Set(ByVal value As String)
_Line = value
End Set
End Property
Public ReadOnly Property FirstName() As String Implements
Name.FirstName
Get
Return Mid(_Line, 1, 30)
End Get
End Property
Public ReadOnly Property LastName() As String Implements
Name.LastName
Get
Return Mid(_Line, 31, 30)
End Get
End Property
End Class
End Class
-----Original Message-----
From: Discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Ernst Kuschke
Sent: Thursday, November 16, 2006 10:19 AM
To: [email protected]
Subject: Re: [ADVANCED-DOTNET] Data Structures in .Net?
Jon Rothlander,
1. C#, as well as the other .NET lanuages, including COBOL.NET, can all do
what you wish to do.
C# does support the positional format you want. What the nice people here
are trying to do is help you, by saying that it's a stupid idea. Today there
are better ways to do what you want.
2. .NET programmes DO NOT understand COBOL, and thus they can't maintain
your solution of COBOL-style C# (or Java). To do that, you will need to find
guys that have an astounding sense of humor, as well as know both COBOL and
.NET. Expensive.
3. It doesn't sound as if you have lots of OO experiece, so I suggest that
you read up on the subject.
Write your first few classes. You will realise what these posts mean.
Case closed.
PS - With that budget, I could come help to port this to .NET, elegantly and
extensibly, as a "highly paid consultant" :P
--
Ernst Kuschke
MVP - C# (South Africa)
http://www.ernstkuschke.com
On 11/16/06, Frans Bouma <[EMAIL PROTECTED]> wrote:
>
> > Also, what isn't supported in the COBOL for .Net. Is inline SQL
> supported?
> > If not, that more of an issue than my problem with the data
> structures. If
> > I can port 90% or more of the code to .Net, is that better or worse than
> > COBOL not supporting inline SQL. I'm sure the COBOL solutions has
> issues
> > that it cannot support at well.
>
> May I ask if you've really read a lot of the posts in this thread?
> If so, you'd have known why the thing you wanted is silly
> in-memory and also why mutating string buffers isn't supported and why
> that's a good thing.
>
> Inline SQL is not recommended for maintenance reasons. One should
> use a proper module to do the data-access, either through
> o/r mapping or through *shiver* stored procs.
>
> > >>Java old, .NET new, looky! we smarter and cheaper - I think these are
> very
> > >>important messages to convey to the client.
> >
> > Yeah, but you know what they are going to say.... Why can't we handle
> data
> > structures? So in their mind, who's smarter? If COBOL can handle it,
> why
> > not C# and VB? In the end, it's all just MS ilCode.
>
> I give up. :-/
>
> FB
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentorR http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
