> I just wanted to point out the reason we are doing this because a number of
> post have suggest not try this at all. Here's the basic reasoning behind
> attempting to this and not just wanting to rewrite it.
>
> The options for the client are really pretty simple. If there is no
> solution in .Net, the client will simply throw out .Net as a solution, as
> .Net doesn't look like it can handle this. They would have the option of
> working with other .Net languages such as COBOL for .Net, which kind of
> destroy the whole point of moving to .Net in my opinion. So I find it hard
> to recommend that to a client.
that's all fine, but still it doesn't explain anything about why the
client wants to have this variable solution. The thing
with this is that it's a pure technical issue, or better: your problem is
caused by a solution you thought would solve the problem
of having lots of string manipulation code.
You haven't specified why you want all the variables should be filled
from the concatenated version (the _full version)
while it should be the other way around: the FULL version should be the one
which is concatenated from the snippets and thus
readonly.
> The odd thing here is that this is being done in Java without any issues...
I doubt it.
> or at least the issues where not big enough to throw out the solution. So
> in my opinion the client would simply choose Java over .Net since .Net
> cannot handle this. The estimates that we are coming up with are about $20M
> to rewrite and about $300K to $600K to migrate the code in Java. So it
> would be hard for a $10M company to pick .Net over Java with the price tag
> of $20M compared to $600K. No matter how many points we give them in
> regards to how .Net compares to Java, the price tag along will kill it.
is that 20million $ for a single piece of software? And this 'issue' is
the deciding factor? I fail to see the logic behind
that.
Because: why would someone want to type in values like:
"Jon Rothlander Gregory "
which then should be split up into values of other variables? That's
completely against how a 3rd gl works. In C you could
perhaps do a little pointer voodoo but then too you'll run into issues REAL
FAST if one of the variables has to contain a variable
longer than the allocated length.
The last time I saw this kind of byte voodoo was on the Amiga 500 where
blitting pieces of data on top of code resulted in
code with new input.
So you should look in having the Name_Full property be constructed in
real time from the properties Name_First, Name_Middle
and Name_Last and which is read-only. Your editor then should work with these 3
variables, which AUTOMATICALLY would result in an
updated Name_Full.
Any other way is IMHO wishing you'll get enlisted on
www.thedailywtf.com sooner or later. And sorry for being blunt here,
but it doesn't matter how big pile of money is at stake: it doesn't make the
software suddenly special, you still should follow
normal OO principles. :)
> I don't know how Java is able to do this, but it does. There are legacy
> tools to translate this code into Java... and they work.
Well, why not look at the java code and see how it's done? I'm pretty
sure they'll use arrays under the surface and the
getters of the variables convert the array snippets into strings, which is
horribly slow and useless coding.
Because: WHY would you want to go there in the first place? Because you
want to start with the full version. It would be
great if you could explain that reasoning first, so perhaps there are OTHER
solutions to that requirement than wasting a lot of cash
on a 'solution' which will never work properly.
FB
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
