[fpc-pascal] Namespaces Support

Dmitry Boyarintsev skalogryz.lists at gmail.com
Sat Oct 26 07:03:12 CEST 2013


Not really namespace related, but:
Most of the commercial/free/open source Delphi/FPC libraries are backward
compatible to D7-D6 (including all Delphi-win32 versions)
That comes with a cost (a bless) of not using new language syntax (as much
as possible).
And typically include a long-long ".inc" that instructs the compiler to be
as much convservative as it can (fighting Delphi cross-version
incompatibilities)

So from language environment perspective, the hard usage of "namespaces" is
most likely will be limited to a certain set of projects.

thanks,
Dmitry


On Fri, Oct 25, 2013 at 10:18 PM, Fabrício Srdic
<fabricio.srdic at gmail.com>wrote:

> I know I'm a newbie in fpc, but I don't see backward compatibility a
> reason enough to leave to implement some improvements, like organize the
> base units of the fpc into proper namespaces.
>
> As Michael and Sven said, if Delphi itself is not fully compatible among
> versions, why should fpc be?
>
> According to the on-line documentation, fpc has five units that are
> specific to the Unix context. So, why not keep them in a Unix specific
> namespace? If we have several elements that are platform-independent, why
> not keep them in a specific namespace, like e.g "System"?
>
> As the number of units of the fpc increases, keeping related elements
> logically organized can even facilitate maintenance tasks.
>
> To a novice like me, would be easier to locate and to identify what
> elements which are present in a e.g Windows.API.Messages or
> Windows.API.Mutex unit than in a huge Windows unit.
>
>
> 2013/10/25 Michael Van Canneyt <michael at freepascal.org>
>
>>
>>
>> On Fri, 25 Oct 2013, Marco van de Voort wrote:
>>
>>  No one forces anything. You can perfectly set the default namespace to
>>>> 'fpc' (or whatever) in the default config file, and all should compile
>>>> as it was.
>>>>
>>>
>>> Yes. One can live with the XE2+ renaming at the cost of renaming units,
>>> potentially fixing breakage later, and a lot of adaptation of existing
>>> configuration, scripts etc.
>>>
>>> But I repeat: what is the hurry?
>>>
>>
>> I am not hurrying anything.
>>
>> Where did you see me saying anything about timeframes ?
>> The necessary default namespace support is not even there.
>>
>> I'm discussing principles, not timeframes.
>>
>> And the issue of compatibility: It is a bogus discussion, you know this
>> as well as I do.
>> If Delphi itself is not compatible between versions, then we cannot do so
>> either, and must choose a version to which we are compatible (2 versions if
>> you accept/count the 1-byte RTL).
>>
>> Whether that turns out to be D2009 or DXE1/2/3/4/5: I honestly couldn't
>> care less.
>>
>> Michael.
>>
>> ______________________________**_________________
>> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.**org<fpc-pascal at lists.freepascal.org>
>> http://lists.freepascal.org/**mailman/listinfo/fpc-pascal<http://lists.freepascal.org/mailman/listinfo/fpc-pascal>
>>
>
>
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20131026/ed1e6090/attachment.html>


More information about the fpc-pascal mailing list