Re: Thinking Clearly


"Brian Moelk" <bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:44b2cf42$1@xxxxxxxxxxxxxxxxxxxxxxxxx
Dan Barclay wrote:
In that respect, I don't see much tangible difference between .NET or
Win32 as Interop is a perfectly suitable solution. This is something
.NET has been designed to do: leverage "legacy" code.

<blink> <blink> Huh?!!

Where have you located *legacy* .Net code, and just how do you define
legacy?

"Legacy C#"???

"Legacy VB.Net" http://vb.mvps.org/vfred/breaks.asp

How the heck can there even *be* legacy code in .Net since .Net is
just upon us?

Not legacy .NET code, but "legacy" code. .NET has hooks to use COM
objects, etc.

Ahhh... COM interop. The worst of both worlds <sigh>.

Reading this might help:

http://www.artima.com/intv/interop3.html

That does *not* move legacy code forward. It lets you *get to* legacy
functions in their previous form. It makes as much sense as calling 16bit
DLL's from Win32. Nice shortcut at the time, but does it make sense now?

FWIW, everything you're hearing now about "designed for the
future" you heard before with MSDOS, OS/2, Windows, Win32.

Certainly, but the heart of MS' products at the moment is a mixed-mode
C++ compiler. I think there is some safety in creating the same
analogue with Delphi.

Believe what you want.

If you want your code to survive to be true legacy code, I strongly
recommend you review coding practices to include platform
isolation/insulation.

Sure.

Either create your own wrappers, or use wrappers you
think you can trust to move forward with your code for Platform.Next
(perhaps VCL?<g>).

Certainly, like COM or a Web Services wrapper.

Never trusted COM for that myself. I'm one of those who has only as much
COM as is required to expose functionality outside the executable.

<shrug> Implementation pitfall (as opposed to a system brick wall), isn't
it? As there are implementation pitfalls, I'd have to assume they'd be
identified and, where justified, additional development to eliminate
them.

As it stands now, to eliminate them, you'd have to eradicate VCL.NET.

No, I'm afraid I wasn't clear or you misunderstood. If they are, in fact,
pitfalls for the user base then Devco would be smart to work on eliminating
the pitfalls from VCL.Net. I was not proposing that we should have to
eliminate VCL.Net from our apps in the long term.

"The *best*" is, at best, a subjective term dependent on your objectives
and
a number of other things. What you consider "best" may not be what
someone
else considers "best".

I never said otherwise.

Sorry, I assumed when you said "because it's not the *best* .NET solution"
you intended the "the" to mean only one "best". My point is that, perhaps,
the current solution *is* the best from someone's standpoint. Or, maybe
not. So far I haven't found a "the best".

Dan


.

Relevant Pages

  • Re: Thinking Clearly
    ... Win32 as Interop is a perfectly suitable solution. ... .NET has been designed to do: leverage "legacy" code. ... Implementation pitfall, ...
    (borland.public.delphi.non-technical)
  • Re: .NET
    ... "WinFX and Win32 will coexist side-by-side, but parts of Win32 will be ... considered "legacy" starting with Windows Vista, just like Win16 was ...
    (borland.public.delphi.non-technical)
  • Re: Thinking Clearly
    ... Win32 as Interop is a perfectly suitable solution. ... .NET has been designed to do: leverage "legacy" code. ...
    (borland.public.delphi.non-technical)
  • Re: My rant about the "throw out delphi and re-write it in C#" crowd.
    ... The problem is that Win32 will be "legacy" in terms of coding ... For instance even today there is NO other Win32 RAD ... your ability to deliver mainstream technology solutions. ...
    (borland.public.delphi.non-technical)
  • Re: Thinking Clearly
    ... How many within the Delphi community are using ... It doesn't leverage the things that the .NET framework ... designed from day one to be able to interop with all sorts of "legacy" code. ...
    (borland.public.delphi.non-technical)