ses for imported units, and making them required on each
symbol reference, will not affect compilation speed or lookup for
unqualified names.
Lookup for qualified names is faster than lookup for unqualified names.
Regards
Timothy Madden
___
fpc-
ncommon case. This is a step back, not forward...
>
>> Timothy Madden want this, not me. ;-)
This is necessary in order to guarantee thare can be no conflicts
whatsoever. No matter how many units you want to USE in your program, no
matter what versions of the units.
It is not that bad,
Without a single warning from the compiler.
Thank you,
Timothy Madden
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 08/21/2012 06:06 PM, Marcos Douglas wrote:
> On Mon, Aug 20, 2012 at 1:15 PM, Timothy Madden
> wrote:
[...]
>> Is there any form of proposal or some alternative to the USES clause,
>> that will keep all the imported symbol names qualified by some namespace
>> name or
in the thrid-party unit are now automatically
exposed and public in the wrapper unit ?
If so, is there a way to expose and make public the types, classes,
variables and functions from a private (implementation) unit ?
Thank you,
Timothy Madden
___
fpc
On 08/21/2012 10:30 AM, Jonas Maebe wrote:
>
> On 20 Aug 2012, at 18:15, Timothy Madden wrote:
>
>> This story is inspired from a real case when *lots* of user code
>> suddenly stopped compiling after JDK 1.2 was released, with a new List
>> class, which users had
me some shorter qualification,
because with the current qualified names, the qualified name can be
really long.
Thank you,
Timothy Madden
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
