On Fri, 16 Jun 2006, ik wrote:
OK I'll answer everything from this email ...
On 6/16/06, Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
On Fri, 16 Jun 2006, Mattias Gaertner wrote:
>>>> 3. Better/Faster IO usage ;)
>>>
>>> Better designed I/O libraries/classes ?
>>
>> Better way to control the I/O buffering etc... so we will not need to
>> "hack" our way to have bigger container then 255 chars...
>
> Perhaps even better: Automatically adapting the buffer size.
> The RTL must work with all kinds of programs. There is no single best
buffer
> size.
Because of this, there is the SetTextBuf() call. This is not a hack.
Only the programmer knows what the usage of a particular file will be,
so only he is qualified to make the call.
Well, the problem is that sometimes it's not that easy to tune
things... If everyone here is talking about newbies, then how would
they cope with such tunning tool ?!
Newbies don't write code that requires such tuning in the first place.
So the problem is academic.
The point is: there is some standard behaviour. If it doesn't fit your
needs, OK, there are ways to tune it without 'hacks'. That's about all
you can expect from a language/RTL IMHO.
>>>> 4. The amount of classes that comes with Java as part of the compiler
>>>> :P
>>>
>>> Can live with them. Make your own libraries.
>>
>> You are loosing the reason to work with Pascal. When you have ready to
>> use libraries that come with the language, you increase development,
>> and it means that you can show what the language can actually do. You
>> need a complex graph, plotting etc calculation ? use the "GraphMath"
>> unit... You need an XSLT(2) support ? use the xslt unit. You need SNMP
>> traps support ? use that unit ...etc..
>
> AFAIK the FPC team adds happily new classes to the standard/extra
packages.
> Just contribute.
Exactly.
I was declained more then once to add libraries that I wanted to FPC,
and I was asked to make it "thierd party" tool in contributed units...
Only general puposed tools usually accepted... Now it's good, but not
enough... we need something like "package manager" for libraries like
perl's cpan idea, or the linux/bsd ways...
We are working on such a package manager.
>>>
>>>> 6. "inline" code inside class (like in C++/Java).
>>>
>>> Not recommended. Bad design.
>>
>> Huh ?!
>>
>> destructor Destroy; override;
>> begin
>> inherited Destroy;
>> end;
>>
>> Why should i place it somewhere else ?! To remind you, I could use
>> "inline" command in order to place code of functions in the interface
>> sections on TP... So the Pascal language do have history of such
>> things ...
The above code is superfluous. you don't need this code at all.
Why ? If I have less of 10 lines of code to write, it's easier to
write it in place IMHO ...
That's simply "personal laziness", so to speak.
We're talking about language design:
The point is strict separation of interface and implementation.
This is a language design principle.
Michael.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
