Hi!

Am 26.07.2010 10:40, schrieb Graeme Geldenhuys:
Op 2010-07-26 10:14, Sven Barth het geskryf:

Regarding your ideas 2 and 3: as they are not Delphi compatible they
might be considered a "bad thing" (TM) by the FPC developers.

Currently FPC developers do not want to implement the "dotted" namespace
idea from Delphi - though they already stated there stance on Delphi
compatibly regarding this. In short - Delphi in-compatibility is not a
problem here, just like Generics or Compiler Modes or ..... FPC doesn't do
everything like Delphi, sometimes it does things _better_ than Delphi. FPC
Namespaces would hopefully fall under the latter.


I hope this, too. And personally I am not interested in Delphi compatibility because I only use Delphi (6) at work and there we use a stable set of compatible components. And the few times I used units from FPC to achieve something (TProcess, SQLite interface unit) I was able to adjust them to the Delphi compiler.


The problems of all three (or maybe all namespace ideas) is that they
aren't compatible to older versions of Delphi (and FPC).

I don't see this as a problem at all.

   * Currently they have unit name conflicts. No solution other than
     renaming the offending unit. Even if they introduced the "dotted"
     namespace idea from Delphi, it is not supported by FPC, so you
     still sit with a problem. You are forced to rename the unit. See
     the RxLib example.

   * Simply upgrade your FPC to a newer version. FPC is FREE. You don't
     have the burden of Delphi upgrade costs. FPC development is open,
     so you can prepare your code as you see things change in FPC, so
     that when a new version comes out, you already are compatible with
     it (again unlike Delphi - remember Unicode support in Delphi. Users
     had no warning of its syntax and required changes until AFTER Delphi
     was released.).


Yes, FPC is free and examples where an older version of FPC is needed can only be constructed artificially, but the Delphi case still holds. E.g. tiOPF supports Delphi besides FPC. I don't know the unit structure of tiOPF but suppose you have a unit "utils" that once conflicted with a Delphi unit and was renamed to eg. "tioutils". Now FPC introduces the new namespace system and you'd like to jump the train and make tiopf "namespace aware". Now you rename the "tioutils" unit again to "utils" and set the prefix to "tiopf". Now you've upset the Delphi users in two different ways:
1) They need to change their uses clauses
2) Now the unit conflicts again with a Delphi provided "utils" unit (does Delphi have a "utils" unit? it's an example after all...)

Or would you keep the "tioutils" unit name and just introduce the namespace? But what did you gain then?

So... what is your suggestion for such packages providers to solve the problem?

Please note again: I'm not against this "unit Foo namespace Bar" idea and the more I think about it the more I like it, but I also tend to see problems that arise because of such a feature and to discuss solutions for such problems.

Regarding your idea 3:
As FPC can use different directories for the search paths how would you
solve similar hierarchies?

Idea 3 is crap - I see lots of issues too, but thought I would mention it
simply because that is what JAVA uses.


I didn't want to say it that directly ^^

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Reply via email to