In Tokyo - CodeGear Developer Camp and Codezine.jp Developer Summit 2008
I am in Tokyo this week attending the 8th quarterly CodeGear Developer Camp. On Tuesday I presented a CodeGear update including news about JBuilder Application Factories and also plans for the next update for 3rdRail. I also presented technical sessions about Ruby on Rails development and higher levels of reuse using Application Factories.
Yesterday I attended the Developer Summit 2008 conference in Tokyo. I took part on a CodeGear Japan sponsored Ruby Community panel discussion. During the panel, we talked about the state of Ruby, the acceptance of Ruby and Rails inside and outside of Japan, and what the community can do to help Ruby move forward. In afternoon I also spent a little time with Yukihiro Matsumoto, creator of Ruby. I had the chance to show him the latest version of 3rdRail.
On this trip I am also talking with the press about native, managed, and dynamic language programming. There is keen interest among Delphi and C++ developers in Japan about our work to Unicode enable the next versions of Delphi and C++Builder. Stay tuned to CDN for additional Unicode events and information.
Here is a summary of bullet points from my Developer Camp presentation about our directions for Unicode in Delphi and C++Builder:
String will map to UnicodeString
- UTF16 (word-sized) elements instead of byte sized elements
- If you need AnsiString you still can use it, but string will not map to AnsiString
- Delphi .NET strings are already Unicode strings
- SizeOf(Char) will not equal Sizeof(Byte)
Character indexing and normal string manipulation remain unchanged
- The UnicodeString is still a 1-based index, reference counted, lifetime managed entity.
- String assignments, indexing, implicit conversions, etc all continue to work as expected.
- Length(UnicodeStringVar) returns the number of elements the same as Length(AnsiStringVar).
Compile time warnings
- When the compiler sees certain code constructs such as implicit string conversions, strange pointer casting, etc extra diagnostic information will be output.
- Another compiler feature we’ve added is the ability to elevate any one or all warnings to be an error.
Our goal is to ensure that the vast majority of our users will see as little disruption as possible
- We’re working on providing tooling and education to assist in this transition.
February 14th, 2008 at 6:32 am
Hi
Could you please also have someby provide some info about the DB issues involved with the switch to Unicode. I am thinking about things like TStringField, TWideStringField etc. Or will this stuff "just work"? Right now there is a lot of TStringFields "sitting on top" of actual database fields that are not Unicode.
February 14th, 2008 at 9:00 pm
>
This decision is IMO very unfortunate and wrong.
I can surely convert my code replacing all Strings by AnsiStrings and fix some remaining issues but how can I be expected to convert and test all toolboxes I use whose inner workings I do not understand sufficiently (nor do I care to), many of them being open-source or from companies gone bust since long ???
But let me ask another question :
RAD Studio 2007 being probably the last RAD Studio I will ever use, will Codegear :
1. continue to maintain the 2007 version in the future, delivering updates to fix bugs (at least) (even as a paid service) ?
2. continue to sell the 2007 version (there can be new people in developer teams) ?
I sincerely hope you have a positive answer to both questions and I would like to hear it. Otherwise, I would say you do not know what you are doing.
March 14th, 2008 at 4:50 pm
[…] think my best (and simplest answer) is to show a picture (below) taken during my afternoon hotel room meeting with Yukihiro Matsumoto (’Matz’) at the Developer Summit with Ruby running on an Apple […]