On Fri, Apr 13, 2012 at 12:18 PM, Jürgen Hestermann <juergen.hesterm...@gmx.de> wrote: > Lukasz Sokol schrieb: > >>> IMO it must be possible to predict the encoding of strings >>> when writing the code (without running the program). >> No one prohibits you to use an identifier name to reflect encoding ;) > > That's true and that's what I am doing of course. > > But if you use a function from a (Free Pascal or Lazarus) library it is not > clear which kind of encoding this function expects. As I already mentioned, > for example CopyFile (from LCL) and FindFirst (from SysUtils) have no hint > in their documentation on what encoding is expected. I know, somewhere it > says that library x has enconding y but why wasn't this information written > to the documentation for the indiviudal functions? I don't get it. It's a > very important information. I think that many Free Pascal (and Lazarus) > users come from other platforms like Delphi, Virtual Pascal, Turbo Pascal > etc. and many want to use parts of their old code. These people do not sit > down for months to find all the spread information that *may* be important > for FindFirst, CopyFile, etc. They expect all releveant information at the > docu for the functions.
+1 >> Also : how do you think you'd guess encoding of a text file on disk >> before reading it ? Some people don't like to have the decision taken >> by the compiler for themselves... > > That's not what we are talking about here. If I understood Marcos problem > correctly the topic was the output of another function where the encoding > was unclear. That was one of problems. >> Other area where this may be important: web applications. >> Database fields may (each) have different encoding (and we would be able >> to know it), >> internals of the app would work on their own encoding (and we would know >> it) >> the web frontend may run on different encoding every time (and we would be >> able to know it ) >> (imagine somebody forces a certain encoding on their web browser and tells >> the web app developer to support THAT) > > As long as you *know* about each encoding you can manage it. But if you have > to guess the encoding then it will fail in general. The major problem is work with FPC (Ansi), LCL (UTF8) and Console on Windows (UTF16)! >> I for one /like/ that The New Pascal has become highly customizable even >> if >> some things have to be more explicit than in Ye Olden Days... >> It's still way more 'high level' than plain c that some people dub >> 'assembler on drugs'.... > > I only see that everything that has been added since Delphi (mainly by > Borland) is more C style than Pascal (pchar, operator overloading, context > dependend meaning of indentifiers, poor documentation, etc.). The focus is > more on a "me too" attitude (assimilation of all all other programming > languages) and not on clear, easy and readable program code. Marcos Douglas -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
