Re: [fpc-devel] out parameters in RTL/FCL

2005-06-10 Thread Peter J. Haas
on 2005-06-10T08:47:04+02:00 Peter Vreman wrote:
 You are only asking for features that cost us free time to
 implement. But you don't want to donate free time to fpc by
 submitting a patch.

Was kommt es zu solchen unsinnigen Vorstellungen? Arroganz,
fehlgeschlagene Hellseherei, Paranoia, eine Kombination daraus oder
ganz was anderes?


Wie auch immer, ich denke, ich muß mich entschuldigen. Ich habe
offensichtlich den Sinn dieser Mailinglisten falsch verstanden. Sie
scheinen nur dazu zu dienen Patches abzuliefern und nervenden
Anwendern ihre Vorstellungen auszureden. Alles andere scheint den
Horizont bestimmter anwesender Leute zu überschreiten.

Gibt es irgendwo ein Forum, gern auch in Form einer Mailingliste, wo
motivierte Entwickler Vorstellungen und Lösungen zum FPC in Ruhe,
sachlich und konstruktiv diskutieren können, bevor sie sich,
vielleicht sogar mehrere gemeinsam, daran machen, einen Patch zu
entwickeln? Also ein Forum, wo keine Leute anwesend sind, die anderen
permanent unterstellen, sie würden nur ihre kostbare Zeit stehlen
wollen, nur weil sie ihren täglichen Patch noch nicht abgeliefert
haben und die damit jede Diskussion abwürgen.

Und falls nicht, gibt es kompetente FPC-Kern-Entwickler und/oder
motivierte FPC-Gelegenheitsentwickler, welche bereit wären, in einem
solchen Forum zu diskutieren?

Ich wäre gerne bereit dort aktiv mitzuwirken, es würde auch meine
Voraussetzungen erfüllen, nicht triviale Patches zu entwickeln ohne
fürchten zu müssen, für den Papierkorb zu arbeiten. Und keine Sorge,
für solche fachlichen Diskussionen reicht mein Translater.

MfG Peter.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] out parameters in RTL/FCL

2005-06-09 Thread Peter J. Haas
I write in German language because I'm not able to translate my
statement comprehensibly. Maybe anybody can translate it for people,
which don't can read German.

on 2005-06-08T21:24:42+02:00 Peter Vreman wrote:
 At the moment there are a lot of warnigns for uninitialised var
 parameters.

 Is it possible to replace the 'var' with 'out' specifiers?
 Can I send patches for that?

 Yes, you can send them to me or florian

Das Thema wurde hier vor ein paar Wochen schon einmal in der
FPC-Pascal Mailingliste diskutiert. Die oben erwähnten Warnungen
tauchten auf, wurden von Peter Vreman mit der damals neuesten Version
nicht gesichtet und von Jonas Maebe als Bug bezeichnet.

Ich hatte ein wenig darüber nachgedacht und fand, daß eine Meldung auf
nicht initialisierte Variablen bei var-Parametern durchaus Sinn machen
kann, wenn diese ausschließlich als in/out-Parameter eingesetzt
werden. Weiterhin müßte sich ein solches Feature abschalten lassen,
denn wer will schon gerne wegen einer neuen Version auf die Schnelle
seine Quelltexte durchgehen, um die vielen plötzlich auftauchenden
Warnungen zu prüfen und festzustellen, daß sie nicht stimmen.

Wie auch immer, ich dachte mir, daß man 'vorbereitender' Weise
wenigstens die mitgelieferten Bibliotheken (RTL/FCL/LCL) entsprechend
aufbereiten sollte, also bei reinen in-Parametern const, bei reinen
out-Parametern out zu verwenden. Nun war ich mir nicht sicher, ob
const und out bei allen Compilermodi zur Verfügung stehen, und bevor
ich mir umsonst Arbeit mache, fragte ich nach:

PH I don't know, whether other compiler modes support const and out.
PH If yes, the RTL/FCL/LCL functions should use it. This do mean e.g.

Ich bekam daraufhin von Peter Vreman folgende Antwort:

PV For compatibility we can't do this. Delphi also doesn't warn. And
PV making the warning dependent on the compiler mode will make things
PV too complex. Because it then dependents on the compiler mode used
PV to compile a used unit that contains a function and not on the
PV compiler mode used in the current unit.

Nun auf einmal gelten diese Einwände offenbar nicht mehr. Der Bug
wurde zum Feature erklärt, die User müssen zahlreiche falsche
Meldungen hinnehmen. Keine der von mir bereits vor Wochen erwähnten
Vorbedingungen sind erfüllt, die das verhindert hätten.


Ich bin vor einigen Wochen zum FPC gestoßen, weil mich jemand
eingeladen hatte. Ich bin Delphi-Anwender und werde das beruflich
bedingt auch in Zukunft bleiben. Mag sein, daß ich in der Zukunft mal
etwas mit Lazarus realisiert hätte, im Moment gab es jedoch keine
Notwendigkeit irgendein Feature unbedingt implementiert zu bekommen.
Ganz im Gegenteil, mein Ziel war es gewesen hier mitzuwirken, d.h. ich
war bereit, mich den von mir genannten Aufgaben auch zu stellen. Nur
bin ich nicht bereit, so etwas ohne vorherige Diskussion mit anderen
zu tun, wenn ich alleine programmieren will, kann ich das auch in
eigenen Projekten. Aber in keinem Fall bin ich bereit, etwas gegen den
erkennbaren Widerstand der Kernentwickler zu tun. Leider hat Peter
Vreman es immer wieder verstanden, jede einzelne Diskussion, an der
ich mich beteiligte, oft mit bei genauer Betrachtung unsachlichen
Argumenten abzuwürgen (siehe u.a. oben). Er stellte klar, das es nur
einen Weg gibt: Wenn ich etwas will, dann soll ich doch einen Patch
einreichen. Wenn dieser dann den Kernentwicklern gefällt, habe ich
vielleicht eine Chance, daß er aufgenommen wird. Ich bin doch nicht
blöd und arbeite in meiner Freizeit für den Papierkorb, das mindestens
er etwas dagegen hat (ohne sich damit ausreichend beschäftigt zu
haben), war ja bereits deutlich erkennbar. Und bei mehreren der
Probleme hätte eine Lösung Änderungen im Design des Compilers
notwendig gemacht, eine solche Entscheidung trifft man nicht ohne
vorher mit denjenigen darüber diskutiert zu haben, die sich da
auskennen, Nebenwirkungen besser überblicken können.

Mir ist dann in einer privaten Diskussion über meine Verärgerung von
einem Dritten erklärt worden, daß mich Peter Vreman wohl mit einem der
vielen nervenden Anwender verwechselt hätte. Egal ob dem so ist, oder
nicht, ich finde es unverschämt Anwender welche sich am Projekt
beteiligen, auch wenn sie nur auf Probleme aufmerksam machen oder
Ideen zur Verbesserung des Projektes einbringen, dermaßen arrogant
abzufertigen.

Ich hatte bei den Mails von Peter Vreman permanent das Gefühl, daß er
nur schrieb, um mich zum Aufgeben zu bewegen, das es zu keinem
Zeitpunkt darum ging, irgendetwas sachlich zu diskutieren. Mir war
übrigens bei der Einladung versprochen worden, daß genau so etwas hier
nicht vorkommt, leider ist dem wohl nicht so.

Ohne die Einmischung von Peter Vreman hätte es vielleicht die eine
oder andere konstruktive Diskussion gegeben und höchstwahrscheinlich
wären bestimmte Dinge, wie das Ersetzen der betreffenden var Parameter
durch const und out und abschaltbare Hint-Gruppen längst realisiert,
zumindestens hätte ich mich daran versucht.

Um Mißverständnissen vorzubeugen, es 

[fpc-devel] RTL / SysUtils / GetLocaleStr, GetLocaleChar

2005-03-22 Thread Peter J. Haas
Hi,

is there any reason, why GetLocaleStr and GetLocaleChar (unit SysUtils
under Win32) are not published?

wkr Peter.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Friend classes?

2005-03-20 Thread Peter J. Haas
Hi Ales,

on 2005-03-18T10:57:10+01:00 Ales wrote:
 C++ requires friend only because it lacks the idea of modularity.
 Since all classes are apart they need some way to tell each other I 
 can use you
 In pascal you simply put them into 1 unit.

But IMCO this is not really a good OOP-like solution. Above all
because every class in the unit have access to all sections of a other
class, including the private section (at least in Delphi). A real
private section is on my wish list since Delphi 1.

Sometimes is it not possible or meaninful to put all related classes
in 1 unit, e.g. to avoid monster units and split a problem in
surveyable parts, although this classes belong together and are
managed by a furthermore class. Then you need to publish more methods,
as you need for other resp. the actual usage, this softed the
information hiding concept.


Years ago I read a description of a object oriented pascal dialect,
which use a other concept, IIRC called view concept. The developer can
declare different views to a class, which only contain the methods,
which are needed for a concrete problem. I think such a concept would
be the better way.

The developer of a class or component don't need to consider, which
methods / fields he need to set in the protected part. A developer
which derive a class can define, which methods / fields he need and
write a view without any hacks or modification of the origin class.

wkr Peter.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel


Re: [fpc-devel] Hint: Parameter sender not used

2005-03-20 Thread Peter J. Haas
Hi Uberto,

on 2005-03-11T18:35:45+01:00 Uberto wrote:
 This is not a big issue, anyway could we avoid the endless list of such
 similar hints compiling Lazarus and our program?

 Don't make me wrong, I apreciate the hints of the compiler.
 9 times out of 10 if I don't use a parameter in a function or a method there 
 it is an error of mine.
 But in published methods the parameter list is mandatory, so it doesn't make 
 sense to hint them. 
 Moreover they hide real hints.

I agree.

I have (unsuccessful) try to post a similar mail in the fpc pascal
list.

But what do you mean with published methods? The published section is
intended only for properties, which should be published in the object
inspector. I guess you mean event methods. Beside event methods,
callback functions and virtual methods could be affected too.

My main problem, if I hide the hint by using

{$HINTS OFF}
...
{$HINTS ON}

I remove all useful hints as well.

wkr Peter.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel