[fpc-pascal] Re: Namespaces Support

[leledumbo]

> 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.

Backward compatibility is what the market is mostly about, most companies
don't want to change their codebase as much as possible while still getting
new features like new optimizations.

> As Michael and Sven said, if Delphi itself is not fully compatible among
> versions, why should fpc be?

Because fpc is NOT delphi, fpc SHOULD BE better than Delphi IMO (I think
it's already at some points: cross platform compatibility, proof of compiler
capabilities through bootstrapping, etc).

> 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.

Novice would become intermediate and advanced as time and learning go by,
but the opposite won't happen.

I'm not against namespacing standard units, but there must be a way to
retain backward compatibility. I have huge libraries I wrote myself and I
don't want to change them, while I might need them for new projects. At the
worst, a tool to convert existing code to new one automatically should be
provided, though it's not the best solution IMHO. A compiler option might be
better.



--
View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Namespaces-Support-tp5717153p5717210.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.