Rolf


Out of interest what's your escape route?

Roy Lambert

Rolf,

I do agree with you but also think Delphi must continue to evolve (maybe
just not at this backward compatibility breaking rate and this frequent
release cycle). Direction at least on compiler side is not a bad one
technologically (even if don't like it).

We're using D2007 and (xe2 for 64bit) and don't see any reason why those
won't continue to work "as is" for another 5+ years - especially as
we're running them all in VM these days.

This should allow things to settle in terms of Delphi and Lazarus and
other tech.

Moving forward i see most of the "new" user side to be either
Javascript or in case of mobile (native and/or javascript depending on
app type).

Raul


On 6/24/2013 8:44 AM, Rolf Frei wrote:
> <<<The ANSI stuff is all being deprecated by EMBT, anyways.>>>
>
> This is the most stupid descission of EMBT and this will destroy finally
> the Delphi market completly. I will never ever buy a Delphi version with
> no ANSI Support or any of the other planned ground breaking changes.
> This is the defintiv suicide of Delphi, if they realy do this. Destroy
> the milions of millions of existing 3rd party source code components and
> utilities is so idiotic, I can't believe they will do this realy.
>
> If they do this I will left the Delphi boat finally and what's then the
> future of EDB for me isn't clear to me yet.
>
> Regards
> Rolf

Rolf,

<< This is the most stupid descission of EMBT and this will destroy finally
the Delphi market completly. >>

I doubt it.  Everything else is already 100% Unicode - Delphi is playing
catch-up in this regard:

JavaScript - 100% Unicode with immutable strings (Elevate Web Builder, of
course, is also)
..NET - 100% Unicode with immutable strings

There's really no downside to using Unicode over ANSI other than the amount
of storage required.  But, with storage and machines getting so fast, you'll
never notice the difference.  The only difference is that a character is now
2 bytes instead of 1.  The same is true of 64-bit.  Pretty soon we'll all be
using 100% Unicode, 100% 64-bit compilers and it will be just like 1995 all
over again, just a little bigger.

<< Destroy the milions of millions of existing 3rd party source code
components and utilities is so idiotic, I can't believe they will do this
realy. >>

Frankly, if the components don't already support Unicode, then they're dead
already and you'd probably have to stop using them eventually for some other
reason.

<< If they do this I will left the Delphi boat finally and what's then the
future of EDB for me isn't clear to me yet. >>

For application-level development, you probably won't notice very many
changes.  The hard stuff is really up to the component/system tool vendors
like us.  The one exception might be a situation where you do a lot of
string processing in a certain way - in such a case you have to adjust your
techniques to accommodate immutable strings.

Tim Young
Elevate Software
www.elevatesoft.com

I'm inclined to agree that full Unicode can't come quick enough, but...

I appreciate having Unicode for multilingual convenience.  However, I
have to interface with 3rd party firmware and hardware that is firmly
stuck in the ASCII or, if I am lucky, ANSI world.  Worse I often have
to interface over serial comms.

Most of the COM port components are still using ANSI strings as the
data type which is a pain and  as the use of serial is going 'out of
fashion' there is little to encourage the authors to rectify the error
over their choice.  On the other hand, while I can pump Unicode over
serial, there is not much point when the target is firmly stuck on
ASCII.

All in all I vote for Unicode and like Tim I suspect that the majority
of developers will not find the switch very hard unless they have
specific requirements.

Malcolm