Since it now is possible to define types inside a class, please look at the example below.

the class internal type section continues accross the border of the visibility "protected" => an error is given that after the "f" a "=" was expected (as needed for a new type "f")

Is that intended? Or should a visibility change exit the type section?

program Project1;
{$mode objfpc}{$H+}
type
   Tfoo=class
   private
     type
       TF = (one,two,three);
//    var // enable this and it works
   protected
     f: TF;
   end;
begin
end.

23.07.2010 9:10, Martin пишет:

Since it now is possible to define types inside a class, please look at the example below.

Now = only in fpc trunk, not in the release branch.

Is that intended? Or should a visibility change exit the type section?

This is a bug. I will fix it.

Best regards,
Paul Ishenin.

Paul Ishenin wrote

> Is that intended? Or should a visibility change exit the type section? This is a bug. I will fix it.

What to do with the generics syntax? FPC do this so:

   generic TFPGList<T> = class(TFPSList)
   type public
     TCompareFunc = function(const Item1, Item2: T): Integer;
   var protected
     FOnCompare: TCompareFunc;
     function  ItemPtrCompare(Item1, Item2: Pointer): Integer;
   public
     constructor Create;
   end;

while Delphi do so:

   TSomeClass = class
   public
    type
      TCompareFunc = function(const Item1, Item2: T): Integer;
    protected
     var
      FOnCompare: TCompareFunc;
     function  ItemPtrCompare(Item1, Item2: Pointer): Integer;
   public
     constructor Create;
   end;

Therefore section declarations are incompatible between fpc and delphi. Should this be {$mode} dependent?

Best regards,
Paul Ishenin.

even in this example, the standalone "public" ends the type ?

Don't know which one is best. but IMHO there are 3 ways that could make sense:

1) type, const, ... are nested inside the visibility They end with the visibility => same as they end with the end of an interface section...

2) visibility sections are nested inside type, const honestly, not a good idea

3) combined keywords (IIRC harder to implement if the parser may have to look ahead)
then inside a class "var" can not stand alone, but only iof followed by a visibilty modifier....

Paul Ishenin wrote

What to do with the generics syntax? FPC do this so:  generic TFPGList<T> = class(TFPSList)

Please tell me this was only an example, and that FPC doesn't actually have a TFPGList class somewhere in the code. 'Tfpg' is the prefix I use for all classes in fpGUI Toolkit project- to reduce naming conflicts I had before with FPC. I don't want to go through that again.

In our previous episode, Graeme Geldenhuys said:

All generics types of FPC (in unit fgl) are prefixed with tfpg, since 2006 already.

Marco van de Voort wrote

All generics types of FPC (in unit fgl)  are prefixed with tfpg, since 2006 already.

And fpGUI existed long before that. ;-) I guess lucky for me, Generics are hardly (if at all) used by any developers I know. Still, it's very annoying to get classname or unit name conflicts. The next question would probably be, are there plans for namespace support in FPC - like Java, C#, C++, Modula 2 and Delphi all have?

In our previous episode, Graeme Geldenhuys said:

Afaik M2 has no namespace support (it only supports nested modules), and native Delphi only allows dots in unit names.

Of course the module (unit) concept also includes a namespace already.

This IMO is the wrong way. Remember that visibility sections require (Delphi) that field declarations are not preceded by other (method...) declarations. In so far a visibility specifier is somewhat equivalent to "var". The "interface" and "implementation" sections also are kind of visibility specifiers.

If we ever should agree that declaration sections (var, type...) can be split into subsections of different visibility, then this should apply to the entire interface part, not only to (inside) class declarations. At the same time we should allow for (kind of, implied) "forward" declarations for types, so that the final declaration of non-public types can be moved into the implementation section - reducing chances for circular unit references a lot! (kind of "partial" class declarations?)

DoDi

Graeme, do you remember our conversation, in other thread, about conflicts names?
Marco too, do you remember?
That's I was talking about...

MD

In our previous episode, Marcos Douglas said:

And it still makes no sense. First, that was only about unit names, second it required aliasing everywhere it was used, which was more than the work required to rename.

Marco van de Voort wrote

And it still makes no sense. First, that was only about unit names, second it required aliasing everywhere it was used, which was more than the work required to rename.

Marco, the Generics unit name doesn't clash, but the actual classnames do. So if I use the Generics TFPGList and fpGUI's TfpgList in the same unit, I will have to reference them with the unit name prefix, correct? This is fine.

eg:
uses

    fpg_lists, fgl {generic classes};

 ....
   // create a generic instance
   lst1 := fgl.TFPGList.Create();
  // now create a fpGUI list instance
   lst2 := fpg_list.TfpgList.Create();

Problem is that if the unit names clashed, there is now way around the problem? Or is there?

In our previous episode, Graeme Geldenhuys said:

Yes, renaming. And the problem of this thread is that IMHO all "solutions" that were proposed are worse than renaming. (since they involve changing all places where the unit is referenced. And even then there are significant performance downsides).

Delphi dotted unit names are just a prefixes with a different separator char. Still, while no super solution, it would make duplication less likely (avg unitname would go up), and no ugly cryptic prefixes.

Other solutions that really involve two .pas files with the same name need something to uniquely identify them. E.g. Java does this with the location in the classpath hierarchy, but I doubt we would go that far.

Renaming existing units for one project that conflicts is not a solution/option either.

Marco van de Voort wrote

Delphi dotted unit names are just a prefixes with a different separator char. Still, while no super solution, it would make duplication less likely (avg unitname would go up), and no ugly cryptic prefixes.

Does FPC support dotted unit names? eg
freepascal.rtl.classes.pas
freepascal.fcl.simpleipc.pas
freepascal.fcl.fgl.pas

then fpGUI and LCL (and any other projects) could do similar.... eg:

fpgui.button.pas
lcl.buttons.pas

Currently fpGUI already does something similar (as I stated before) by prefixing all classes with 'Tfpg' and all units names are prefixed with 'fpg_' eg:

fpg_button.pas
fpg_grid.pas

I did this to minimize any possible conflicts, but other projects have not done this, so they stand a much greater chance to get conflicts with FPC or other projects.

I guess Object Pascal users will feel this is "weird" at first - I did too with my change in fpGUI, but you soon get used to it. The benefits outweigh with temporary "weird" factor. I would probably have preferred a "dotted" unit naming format, but I think last time I tried, FPC didn't support a dotted unit name.

Other solutions that really involve two .pas files with the same name need something to uniquely identify them. E.g. Java does this with the location in the classpath hierarchy, but I doubt we would go that far.

Why not something like IInterface or IUnknown does by using a GUID somewhere in the unit.
But then comes the problem that not all editors can generate a GUID via a keyboard shortcut - but then, how to they program with Interfaces (so maybe a GUID is not a issue).

Hi!

No, it doesn't. For the reason see this feature request http://bugs.freepascal.org/view.php?id=14439

Regards,
Sven

Sven Barth wrote

No, it doesn't. For the reason see this feature request http://bugs.freepascal.org/view.php?id=14439

But now FPC is not Delphi compatible. ;-)

Thanks for the info. Like Paul said in that Mantis report, it is rather easy to get around the problem Jonas mentioned - simply add a new language rule (like many existing language rules before it). Oh well.

In our previous episode, Graeme Geldenhuys said:

Renaming existing units for one project that conflicts is not a solution/option either.

Better than using unreadable prefixes or very long unit names.

No, and FPC's will remain the same anyway.

then fpGUI and LCL (and any other projects) could do similar.... eg: fpgui.button.pas lcl.buttons.pas

Nothing stopping you from using fpgui_button.pas now either.

I think that chance is overestimated, unless you use very familiar identifiers (like "buttons").

Typenames are less of a problem, since unit qualification can work around them.

I guess Object Pascal users will feel this is "weird" at first - I did too with my change in fpGUI, but you soon get used to it.

You can get used to live with only one leg yet. But I don't plan to start sawing because of that. Getting used to it is not a reason.

The benefits outweigh with temporary "weird" factor. I would probably have preferred a "dotted" unit naming format, but I think last time I tried, FPC didn't support a dotted unit name.

I think the problem is blown up out of proportion, and the remedies draconical. But if you disagree, just use long unit names.

Because if I think if a 3 letter prefix is draconical and unreadable, guess what my opinion about the userfriendlyness of GUID's is. GUIDs are for meant internal details, not for anything routinely handled by people.

But then comes the problem that not all editors can generate a GUID via a keyboard shortcut - but then, how to they program with Interfaces (so maybe a GUID is not a issue).

And moreover, not all editors generate unique UIDs either.

Marco van de Voort wrote

I think that chance is overestimated, unless you use very familiar identifiers (like "buttons").

Visual objects are not the only area such conflicts occur. Creating your own Container classes, Process controls etc allows for a lot more conflicts with FPC. As FCL expands, so do the chances for conflicts. I've already refused contributing some code to FCL, simple because I want to reduce conflicts at a later date, and the uphill battle with changing something that ends up in FPC. So I follow Martin's (MSEide&MSEgui) advice - keep your code to yourself and under your control. This reduces all kinds of problems later down the line. [sad, but true]

Typenames are less of a problem, since unit qualification can work around them.

No wouldn't it be nice to apply the same idea to unit name problems - apply domain qualification to get around unit name conflicts.

You can get used to live with only one leg yet. But I don't plan to start sawing because of that. Getting used to it is not a reason.

Doing nothing is also no excuse.

I think the problem is blown up out of proportion, and the remedies draconical. But if you disagree, just use long unit names.

The RTL is not so much a problem, thanks to the long history of Borland Delphi - so most developers know what is in the RTL. Now FPC's FCL is a great idea, but the more FCL expands, the more changes there are for conflicts. But I guess dismissing the problem by you, must be acceptable by all (NOT).

I see this as a loose/loose situation. First I tried to use everything FPC has to offer - why reinvent the wheel. But then when you find problems - solution are not accepted by FPC, or the core team makes it so hard for you, you just stop caring or contributing. So then you take option two, implement everything yourself, but now you stand a chance of getting conflicts as FPC grows. FPC don't give a crap about other projects (other than Lazarus), so other projects must just inconvenience their users, by renaming units or classes. A loose, loose situation for us. Having a language feature to accommodate other projects would be nice - after all, most other languages have accepted the chance of conflicting ideas (unit names, class names, etc) and introduced namespace support in the language.

Because if I think if a 3 letter prefix is draconical and unreadable, guess what my opinion about the userfriendlyness of GUID's is. GUIDs are for meant internal details, not for anything routinely handled by people.

My idea was meant to be similar to how interfaces are handled. You declare a GUID when you declare a Interface, but you hardly every have to type that GUID anywhere. The language takes care of that for you. So I was suggesting something similar for unit names. I didn't say it will work, or defined all implementation details - just throwing an idea out there, that could possibly spark some solution. You being super negative to anything is no surprise to me either - what was I thinking.

And moreover, not all editors generate unique UIDs either.

Well, all GUID/UUID generating code I have seen, use the Windows, Linux Kernel, etc API - so if the editor doesn't tap into that, it is their problem, no ours or FPC's.

Namespaces are only solving the problem, if they (the namespace) are by some means guaranteed to be truly unique.

If they are guaranteed, then they are only needed, if this guarantee can for some reasons not be made for the next lower level (e.g units)

If you make namespaces based on the directory, in which a unit is => and fpc allows to have several unit search pathes => then you can find the same directory structure (and therefore same name-space) in several places => the problem still exists.

If you base them on domains, company names, etc => you may have a hope that no one else will do something bad. But no one stops me from creating a namespace "fpgui" anywhere I want (well ijn hte RTL, FCL the fpc team can (and will) stop me).
But then they used the same prefix, of which you thought it would be unique to your project forever => so what gurantees it isn't going to happen the same with namespaces ?

Martin wrote

to your project forever => so what gurantees it isn't going to happen the same with namespaces ?

The greatly reduce the changes of a conflict. Namespaces have already been proven to work. Just look at Java, .NET (Delphi, C#, etc), C++ etc. So I don't think it's needed to argue if namespaces work or don't
- we know they work and reduce chances for conflicts. What we need to discuss, is how to implement it in FPC.

I'll start a new thread of this, seeing that we totally hijacked this thread - my apologies.

What unit name conflicts ? In 15 years that I work with Delphi and FPC, and I have use many many packages, I encountered exactly 1 conflict: the strutils of rxlib, which conflicted with strutils introduced in a later version of Delphi. The RX copy was renamed to rxstrutils, and that was it. If the Rx people had named their unit rxstrutils from the beginning (they did it with all their other units) there would not have been a problem.

I am sorry, but I think that the seriousness of the problem is very much overestimated. Wanting to type rx.strutils versus rxstrutils. Really ?

And let us not forget: most component vendors must support older versions of Delphi, so they are barred from using the dotted unit name syntax anyway.

Most new FCL code gets fp prefixed to unit or type names, so it's not really a problem either. We are aware that we should try to avoid conflicts. It's not like we're looking for them.

I think there are far more important problems than this. e.g. the unicode string type. That is a major challenge, with significantly more impact on usability.

It would be far better to spend efforts on that.

Michael.

And the exact same can be said for longer unit names...

fpgui.buttons
fpgui_buttons
FpguiButtons
....

Namespaces have already been proven to work. Just look at Java, .NET (Delphi, C#, etc), C++ etc. So I don't think it's needed to argue if namespaces work or don't

Namespaces may language dependend have other
properties/functionalities, that may or may not be useful => but that is *not* part of this discussion => so keep it out

The only other thing, if for example looking at JAVA, and that is related to *reducing* ( *not* avoiding) conflicts (and that acts exactly like longer names) is that, for example in Java, due to namespaces, the llibraries provided by java itself also have longer names, There isn't just Buttons, there is java.awt.Button

But then again, if that is part of the solution, you do not need to argue for fpc do have namespace, you need to argue for fpc, to prefix all the units in the rtl, and fcl (buttons being in lcl).

Because if all fpc units were prefixed with a known prefix, then anything a=fter this prefix can never affect others => if they are not, then no namespace, no prefix that you or other use, is ever save from being suddenly used in fpc.

The problem of conflicts is not missing namespaces. It is to short names for units in the rtl/fcl / and it is missing default (known) prefix of all of those units.

And with correct language support, we wouldn't need to make such ugly unit names.

Yes, but that wasn't the original point of the discussion:

Those unitnames avoid conflicts, in the same way than namespaces do => the make the overall identifier of the unit longer.

no namespace is no longer about avoiding/reducing conflicts => it is about making it better looking (better defined by whom?)

Having joined the discussion, and said all that => I don't oppose nor propose the feature. (No one is forced to use it, so it's presence would not affect me)
I simple have said and do say, that it does not solve the original issue of this discussion.

Martin wrote

I simple have said and do say, that it does not solve the original issue of this discussion.

Speaking of the hijacked thread only, with correct namespace implementation, it can indeed solve the problem of conflicting unit names (of existing code out there) without the need to rename units. See my other message thread, option 2. It will also allow me to use the more ideally named unit names like constants.pas and utils.pas in my projects - instead I have to keep coming up with new prefixes. I already have gg_utils.pas, mm_utils.pas, fpg_utils.pas, m2c_utils.pas for some of my projects. It would be awesome if I can simply use utils.pas and define a namespace via a compiler parameter.

my projects - instead I have to keep coming up with new prefixes. I already have gg_utils.pas, mm_utils.pas, fpg_utils.pas, m2c_utils.pas for some of my projects. It would be awesome if I can simply use utils.pas and define a namespace via a compiler parameter.

How should that work? How to distinguish between <std>utils.pas and <other>utils.pas, in "using utils;"?

IMO a directory structure has the obvious advantage, that it can be verified without looking into source code. Namespaces instead are arbitrary per se, and every part of a module (unit) can be assigned to an arbitrary namespace. A dedicated tool would have to build the namespace tree, by inspecting all files (or directories) related to a project (and installation...), before one (including the compiler) can know the contents of every namespace qualifier. The compiler would have to build the namespace tree, in addition to the already existing search path tree/cache. AFAIK .NET build such an global (system wide) cache for namespace resolution - should we really add such a beast as a mandatory requirement for every FPC user? Not to mention the requirement to install every source file (directories) into that namespace manager...

DoDi

Op 2010-07-26 02:45, Hans-Peter Diettrich het geskryf:

How should that work? How to distinguish between <std>utils.pas and <other>utils.pas, in "using utils;"?

I'm thinking in the line of working with something like Lazarus Packages. This is not limited to Lazarus only though. When I talk about a "lazarus package" I mean a set of code (units) that act as one "library" in a sense. Lets use a Lazarus Package (*.lpk) as a simple example.

We have a lazarus package named: fpgui_toolkit.lpk Compile that package with '-namespace=fpgui' and all compiled units are output to a 'lib' directory.

Now we have a project that uses that Lazarus Package as a dependency, referencing the already compiled units directory 'lib' from the fpgui_toolkit.lpk package (this means compiling this project doesn't need to compile the fpGUI toolkit units - they are already compiled). Now lets say this project also contains a utils.pas (fpgui_toolkit.lpk also contained a utils.pas unit). Now if this project wants to reference the utils.pas from fpGUI package, it would use the <namespace>.<unitname> format in the uses clause. If this project only used 'uses utils;' then it would reference the utils.pas of this project (part of the "global" namespace which takes priority" because this project was not compiled with a -namespace= parameter.) and not of the utils.pas in the fpgui_toolkit package.

eg:
uses
utils, // utils.pas from this project - part of "global" namespace fpgui.utils, // utils.pas from "fpgui" namespace

    sysutils;

No if our current project didn't contain a utils.pas unit, then we could simply reference the utils.pas from fpGUI package without the need for the namespace prefix.

eg:
uses
utils, // only utils.pas the compiler knows about (based on

           // search/library paths is the one in "fpgui" namespace.
   sysutils;

See, no need for a global system wide cache like .NET Simply use the search and library paths passed to the compiler. 3rd Party code (like the fpgui_toolkit.lpk package) must be compiled separately if you want them to have a different namespace from the current project. Alternatively, all units must define the namespace they belong to, inside the unit on the 'unit' line. Then you don't need to pre-compile 3rd party units.

eg:

  unit fpg_button namespace fpgui;
  uses
    ...
  end.

Regards,
- Graeme -

Looks nice, but I doubt that it will work. What about units, added implicitly by dependencies? What if such a used unit will/shall become part of another package, later?

When utils.pas will become a member of an RTL package, every unit using utils will have to be updated, in order to reflect the new rtl.utils unit. Then we are deeper in mess than we currently are, without namespaces.

Alternatively, all units must define the namespace they belong to, inside the unit on the 'unit' line. Then you don't need to pre-compile 3rd party units.

Again back to the current state: chance for duplicate namespace names, or required renaming or editing of third party units - as far as source code is ever, I'd agree about (project wide) symbolic names for library directories. Then the file location is given once, in the program or package settings (search path), easily adoptable to any installation, and then a package unit can be qualified (fully optional) by the package name, to override the current unit search strategy.

DoDi

Hi!

Would you mind adding this idea to the Namespace-thread on fpc-pascal, so that there is one place of discussion? (I know that I'm not the list admin, thus it's only a suggestion ^^)

Regards,
Sven

Op 2010-07-26 13:20, Sven Barth het geskryf:

Would you mind adding this idea to the Namespace-thread on fpc-pascal, so that there is one place of discussion?

It also doesn't help that I accidentally posted the new thread to the fpc-pascal mailing list, instead of the intended fpc-devel mailing list. :-(

I think I should create a wiki page to consolidate ideas and example code (similar to what the Generics wiki page was used for).

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

If you use such relatively short and frequently used names, there is a chance. Of course it is a chance over years, and you don't have to take the simplest of names. A prefix is one "solution", but I prefer a bit longer names.

Keep in mind that cooperation must come from both sides....

Kiss of death phrase again. And no, that is no solution, at least not differently than using domain_unitname. Since the different levels have no other meaning, unless you go in the directions of classpath, and change the whole usage and philosophy of how the compiler searches files.

> You can get used to live with only one leg yet. But I don't plan to start > sawing because of that. Getting used to it is not a reason. Doing nothing is also no excuse.

I think so. A minor problem does not always warrant a solution.

Of course, there is more drama to fix such non issues "because we have to do SOMETHING", but IMHO it is much ado about nothing. Worse, non of the solutions are really solutions, or (like in the case of namespaces) not even properly described (designed?) enough to comment on.

I'm a bit careful of namespaces because there are known solutions about how compilers find files (Java, C#), but the practical merger with the Pascal unit system would have to be very carefully described.

Worse, the pascal unit system's inner workings and philosophy would have to be properly described first :-)

No. The problem is real. I just don't think the solutions proposed solve the problem more than simply picking less likely names. (which you could see as a solution either).

Keep in mind that I have seen all those conflicts, and mostly were one word names which were very common. THAT's the mistake. People picking such names set themselves up for failure. (just like when they would use such common names for namespaces later on)

I see this as a loose/loose situation. First I tried to use everything FPC has to offer - why reinvent the wheel. But then when you find problems - solution are not accepted by FPC, or the core team makes it so hard for you, you just stop caring or contributing.

Yeah, yeah, we all know your rants. Most people can cooperate with core fine, but you can't. And of course that is the problem of core.

This is exactly the problem I describe above. Ideas are barely fleshed out, and yet you already dig in.

If your idea was really so great, and this was really a solution, why don't you simply describe it?

Details are important. Fix a few bugs, and be bitten by them a few times....

In our previous episode, Graeme Geldenhuys said:

No it won't. There only will be graeme.geldenhuys.fpgui.constants and when you use that, you will have to USES that too. It is like that in Java too, except you can blanket import a namespace with like

import graeme.geldenhuys.fpgui.*

But that is tightly coupled with the order of files on the filesystem, so a quite draconical solution.

Marco van de Voort wrote

No it won't. There only will be graeme.geldenhuys.fpgui.constants

What a coincidence => I have a unit in one of my projects

unit GraemeGeldenhuysFpguiConstants;

SCNR
Martin

Marco van de Voort wrote

If your idea was really so great, and this was really a solution, why don't you simply describe it?

Yeah, yeah, we all know you have a terrible time maintaining FPC. Most people can maintain legacy software, and still see chance for adding and improving it.

[sorry, could not resist]

Picking longer names for units will also only take you so far, then you will start getting conflicts with those too, then what? I already changed fpGUI's classes to what I thought would be "safe", and look... three years later I see FPC use similar prefixed class names. That idea lasted long - with a saving grace that the unit names differed.

Just offering negative comments and shooting down ideas, do not help this or any other discussion. If you give negative comments, try back it up with an additional suggestion or two. That would be a lot more helpful to this discussion and allow us to more easily find a solution that fit most.

G.

Graeme Geldenhuys wrote

Just offering negative comments and shooting down ideas, do not help this or any other discussion. If you give negative comments, try back it up with an additional suggestion or two.

I've enough great ideas and suggestions but not enought to implement them unfortunatly. So better come up with code instead of endless ideas.

You right, but ... and if we send the code and, even like that, it will not approved?
IMHO, would not it be better to discuss the idea, come to a conclusion and only then implement?

Thanks,
MD

Marcos Douglas wrote

and if we send the code and, even like that, it will not approved?

Within 17 years of FPC, no contribution to the compiler was completely rejected, so no need to worry. And if one still worries: just write a paper/wiki page explaining what shall be done and how it can be implemented.

IMHO, would not it be better to discuss the idea

The person who implementes, decides, so most of the discussion is a waste of time.

Florian Klämpfl wrote

I've enough great ideas and suggestions but not enought to implement them unfortunatly. So better come up with code instead of endless ideas.

Florian, such comments don't help either! As Jonas and Marco keeps saying, FPC development is a two-way street. Ideas need to be discussed before implemented. FPC is *not* a one-man show (well, maybe for you it is). Otherwise I would have implemented many things already
- but I doubt any of those would be applied.

Nikolai Zhubr wrote

sure you know this very well. So, wouldn't it be better to first prepare a consistent formal proposal/description (like Marco suggested) or even a patch - and then if it is clearly good for all and is nevertheless rejected for no reason - only after that start flaming :)

Well what the hell do you think am I trying to do?? I started a discussion on an idea, I created a wiki pages with multiple examples of usage and consolidated some ideas from the mailing list in the wiki page.

The namespaces idea needs to be discussed, a syntax need to be developed if needed, and a consensus must be reached BEFORE it can be implemented.

Graeme Geldenhuys wrote

Otherwise I would have implemented many things already - but I doubt any of those would be applied.

What makes you think so? Which compiler patches did we reject so far?

In our previous episode, Graeme Geldenhuys said:

The namespaces idea needs to be discussed, a syntax need to be developed if needed, and a consensus must be reached BEFORE it can be implemented.

That's where the problems are. A feature is more than just syntax.

Florian Klämpfl wrote

The person who implementes, decides, so most of the discussion is a waste of time.

Then please send that memo to Macro, he clearly didn't get it (referring to previous attempts to contribute code - which Macro clearly said NO to).

[..you guys (core team) really need to get the "rules of the game" straight - there are lots of conflicting ideas between was is and what isn't the rules of engagement...]

27.07.2010 0:15, Graeme Geldenhuys:

IMHO this is somewhat unfair. And generally, it's not like free software usually work. The core devlopers AFAIK are not on salary (at least not for implementing our wishes!). Proper development is quite time-consuming, I'm sure you know this very well. So, wouldn't it be better to first prepare a consistent formal proposal/description (like Marco suggested) or even a patch - and then if it is clearly good for all and is nevertheless rejected for no reason - only after that start flaming :)

Sorry, for off-topic, could not resist :(

Nikolai

Where? I didn't read the whole thread because it is full of the usual noise but as far as I can see Marco said only, that he considers it pretty useless (what I think as well). But this does not mean that it does not go into the compiler (I consider e.g. case <string> of as useless as well, but it made it into the compiler) if someone does a proper implementation (which will be very hairy as far as I can see).

(referring to previous attempts to contribute code - which Macro clearly said NO to).

Where? I cannot rememeber any rejection of compiler contributions.

In our previous episode, Florian Kl?mpfl said:

> (referring to previous attempts to contribute code - which Macro > clearly said NO to). Where? I cannot rememeber any rejection of compiler contributions.

I can't remember refusing code. I can remember refusing some sub 10 lines patches where he renamed generic vars (that were delphi compatible) to something else to free up the generic vars for fpgui. (although Graeme spun it more like "for all the others").

I think it is ridiculous to break Delphi compat for code that mostly still needs to be implemented, and can easily use some other var or name.

Florian Klämpfl wrote

What makes you think so? Which compiler patches did we reject so far?

Lets take some examples in the last few months alone. I had code for the RTL. Iterators come to mind - denied. Then there was a patch for a more cross-platform help type definition - denied. Then there was the discussion about adding Observer support to all container classes in the RTL. Refused again, but at least Michael saw the light and said he will add it to the RTL regardless (and time permitting). I can list a few more... and then some people still wonder why I rant about FPC sometimes.

A developer can only handle so much rejects before they move on to greener pastures. That makes me wonder why I am even bothering with the namespaces suggestion - I should already know the outcome based on past experience. [graeme sulking and crawling back under is rock]

G.

Marco van de Voort wrote

That's where the problems are. A feature is more than just syntax.

An a solution could come from a discussion, so what's your point?

In our previous episode, Graeme Geldenhuys said:

That I don't subscribe to your first bit, that a solution should come from discussion. First make a draft proposal, then discuss.

The whole namespace bit is make up as you go, that doesn't result in the best solutions. First think, then do.

Marco van de Voort wrote

The whole namespace bit is make up as you go, that doesn't result in the best solutions. First think, then do.

Maybe I think and do so fast, you confuse it with thinking its one step. ;-)

G.

Florian asked about rejected *compiler* patches, not RTL.

Marc

Op 2010-07-27 00:13, Marc Weustink het geskryf:

Florian asked about rejected *compiler* patches, not RTL.

And I spoke about code contribution to the "FPC project" - as a whole.

G.

Well, the syntax addition is about the compiler, right? Or do you start the next time to talk about OSS, software, the world in general?

About the observer support. If I got it right, it wasn't your code but Michael's code form some years back. And the idea is not shot down, it's just still under discussion. Just to see if we can come to a better solution. These processes are just slow. That's because there are too many ideas and too little people really writing code, as Florian mentioned before.

In general I think that if you have a new idea _and are willing to implement it yourself_, you can discuss it first. Then try to code some parts, discuss some more etc.etc. Just like Hans-Peter Diettrich is doing right now.

If you need a new feature and you can code it yourself. Go ahead and code. (You can always ask questions or discuss things here) If you don't have time to implement something or don't have the skills, you could ask here and see if some developer is interested, but if that's not the case, let it rest.

Joost.

Okay, thank you for that information (I have a little time with FPC).

BTW, the Graeme makes a wiki here
http://wiki.freepascal.org/Namespaces but there are no all ideas discussed in the mailing-list.
I thought discuss all (good) ideas to put the winning idea on the Wiki.

> IMHO, would not it be better to discuss the idea The person who implementes, decides, so most of the discussion is a waste of time.

But two people can think the same idea and help each other. However, how they know about the ideas of other people? Writing yours thought in the mailing list...

Thanks,
MD

PS: Florian, I understand your side. Even if one idea is very good, maybe can not be implement for many reasons.

Op 2010-07-27 13:54, Joost van der Sluis het geskryf:

About the observer support. If I got it right, it wasn't your code but Michael's code form some years back.

Michael and Sebastian thought about it yes (data binding to controls), but nothing was implemented back then as far as I know (and this was long before Lazarus existed). It's only after Michael saw how I implemented and used the Model-GUI-Mediator design pattern (which heavily uses Observer) in tiOPF, that he modelled his code on that. The code Michael and I would like in the RTL is very similar to what is in tiOPF's MGM.

Check your emails dated 2009-03-15 titled "Lazarus, DB controls, Observers and Mediators".

Anyway, observer is one small example with huge potential, but the trend still holds - most of what I want to contribute is simply shot down. But lets not stray the subject of this thread again.

And the idea is not shot down, it's just still under discussion. Just to see if we can come to a better solution.

Oh like Macro's idea of creating your own RTL is a better solution. Yeah right.

If you need a new feature and you can code it yourself. Go ahead and code. (You can always ask questions or discuss things here)

No point in wasting my time implementing something that will not be accepted. So now I discuss first.

Regards,
- Graeme -

The other core-members and I just try to help. I'm not afraid of a long, time-consuming, discussion with maybe even an conclusion at the end. But I'm affraid that when the discussion is over, no-one is willing or able to develop what has been concluded from the discussion.

'who codes, decides' and 'show us some code first' are not rules, thought out by the core people. It is just that by our experience, it is most productive to work according to those principals.

You could argue that it is not, but it could never replace our 'in-the-field' experience.

But go ahead, discuss the idea, write the code. But if this project fails, realize yourself that you've wasted the time of a lot of people. Time which could have been used better.

Regards,

Joost

Op 2010-07-30 17:58, Joost van der Sluis het geskryf:

I'm affraid that when the discussion is over, no-one is willing or able to develop what has been concluded from the discussion.

I can only speak for myself. My workflow is as follows...

* I see a gap (missing feature) in FPC, Lazarus IDE etc that I would like
* If it's something only I will use, I implement it locally.
* If it's something I think others could find useful too, I discuss the idea on the mailing list.
* If the discussion went well and the idea is still viable, I add it to my todo list.

Just because I discussed something, doesn't mean I will implement it immediately. I have a large todo list, and items that make it onto my todo list, DO get implemented (in my own time).

Regards,
- Graeme -

Joost van der Sluis wrote

[snip]

If people use your time in this thread and this project fails, not to say that these same people would have wasted your time. Maybe it will work, maybe not ... who knows?
The same failure could occur in any other thread, don't?

Graeme Geldenhuys wrote

[snip] Just because I discussed something, doesn't mean I will implement it immediately...

I agree.
Who wants to participate, welcome... who do not, just ignore it.

Regards,
MD

This approach will lead to a lot of wasted time of the core developers. They have to discuss all kinds of ideas, but none of them get implemented.

All developers can think of more new features then they can code. What's the use of discussing all these instead of implementing them? If the core developers would start discussing all their ideas, and only implement them if they have time left, the development will stop.

And please, don't say that we can just skip the discussion. If the core-team would do that the discussion is far less useful, because they can still have some reasons to reject the patch, which were not discussed.

Joost.

Sorry to interject, but the above is a total self-contradiction. You have said that new features should not be discussed, and in the very next paragraph -- that the discussion is mandatory.

Hi,

Please continue this discussion on fpc-other.

Thanks,

Jonas
FPC mailing lists admin

Do not discuss new features if you have no means (time, money, others to do it for you) to implement them.

Following Graeme's workflow mentioned above will lead to those discussions. Discussing new features into great detail is useless if no-one is going to code those features. Wait with the discussion when you want to start implementing.

Read my previous mail in the thread for some more information.

Joost.

ps: I'm wondering what wasn't clear in my mail. Maybe the sentence 'What's the use of discussing all these instead of implementing them?' What I meant is that it is of no use to discuss all ideas first. Then, after all ideas are discussed, start implementing the first one.