How to avoid namespace name clashes after USES ?

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

How to avoid namespace name clashes after USES ?

Timothy Madden
Hello

As the language is currently specified, an identifier is searched in,
and used from, the last unit in the USES clause that exposes that
identifier.

As some might know already, this exposes the user to future
compatibility problems, stemming from the fact that the USES clause
imports and "open namespace" into the user program.

Imagine my perfectly tested scientific computations program uses two
third-party units: Math and Trig. Currently only the Math unit exposes a
log() function that computes the base e (that Euler number) logarithm of
the given argument. All is so good and nice and I get promoted or I get
to another project or to another company and leave the code on the
repository.

An year later a new version of Trig unit is available, the company
promptly upgrades it and after some time someone else needs to make some
changes to, or just re-compile for porting or other resons, the initial
scietific computations program.

Now Trig also exposes a new log() function, which computes the base 10
logarithm for its given argument. Now Trig appears last in the USES
list, after Math.

With no error messages, or even with no changes to the program since 1
and a half year in the repository, the scientific calculations are now
all blown up, and program outputs only errors at runtime. The maintainer
now curses and chases me for having the nerve to leave a program
known as working in such a horrible mess in the repository.

Of course this is a particular case, and in the general case it is most
likely I will get some compilation error, if a unit that appears later
in the USES clause suddenly now defines a previous symbol, that I make
use of in my program. But still, if the program never changes (on
git/svn/cvs), it should still compile later, as it stands...

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 to import from a different package until JDK 1.1.
In this case is wasn't even a third-party library that triggered
conflicts in existing code, it was the system run-time library. Since
that story most Java programmers prefer to import and enumerate each and
every class they use explicitly, instead of importing the package that
provides the classes (I believe there is no equivalent feature in Pascal
that imports only one symbol from a unit).

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 by some prefix I choose ?

Something like:
        import System into sys, Math, Trigonometric into trig;
and then I would need to use trig.actg() as the only possible way to
refer to actg() function in the Trigonometric unit, and to use
Math.log() for logarithm ?

Yes, I know I can qualify names even now if I so choose, but I was
thinking for a way to ensure that qualified names are the only
possibility, and a way that will allow me some shorter qualification,
because with the current qualified names, the qualified name can be
really long.

Thank you,
Timothy Madden

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Jonas Maebe-2

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 to import from a different package until JDK 1.1.
> In this case is wasn't even a third-party library that triggered
> conflicts in existing code, it was the system run-time library. Since
> that story most Java programmers prefer to import and enumerate each and
> every class they use explicitly, instead of importing the package that
> provides the classes

Importing a single class in Java still requires you to specify the full package name, so how would that help preventing compilation failures in case a class is moved from one package to another?

> (I believe there is no equivalent feature in Pascal
> that imports only one symbol from a unit).

Indeed.

> 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 by some prefix I choose ?

Not that I know of.


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

DaWorm

Very tedious, but you could create a wrapper unit and/or class for each library, and expose a prefixed name instead of the original. 

Jeff,

On Aug 21, 2012 3:31 AM, "Jonas Maebe" <[hidden email]> 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 to import from a different package until JDK 1.1.
> In this case is wasn't even a third-party library that triggered
> conflicts in existing code, it was the system run-time library. Since
> that story most Java programmers prefer to import and enumerate each and
> every class they use explicitly, instead of importing the package that
> provides the classes

Importing a single class in Java still requires you to specify the full package name, so how would that help preventing compilation failures in case a class is moved from one package to another?

> (I believe there is no equivalent feature in Pascal
> that imports only one symbol from a unit).

Indeed.

> 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 by some prefix I choose ?

Not that I know of.


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Timothy Madden
In reply to this post by Jonas Maebe-2
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 to import from a different package until JDK 1.1.
>> In this case is wasn't even a third-party library that triggered
>> conflicts in existing code, it was the system run-time library. Since
>> that story most Java programmers prefer to import and enumerate each and
>> every class they use explicitly, instead of importing the package that
>> provides the classes
>
> Importing a single class in Java still requires you to specify the full package name, so how would that help preventing compilation failures in case a class is moved from one package to another?

My problem is about a new symbol in a new version of unit X, overriding
an already-used symbol from unit Y, as soon as I upgrade to the new X
and re-compile.

If a symbol is removed from unit X, as you say, that is obviously a
problem (if not a mistake) with unit X (supposing the symbol was not
deprecated already).

If a symbol is added to unit X, on the other hand, that is a legitimate
(and expected) case, and here you might turn to the language itself for
some help to ensure your future.

By the way, as it turns out C++ has a similar problem with its "using
namespace std;" directive, but it stands a little better in that the
directive is explicitly required before it can have any effect, and user
can also rename the namespace instead, to some meaningfull prefix, to
make it easier to prefix all symbols when used throughout the code, if
they so wish.

Thank you,
Timothy Madden

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Timothy Madden
In reply to this post by DaWorm
On 08/21/2012 02:17 PM, DaWorm wrote:
> Very tedious, but you could create a wrapper unit and/or class for each
> library, and expose a prefixed name instead of the original.

Very ingeniuos, I believe this is as close to a solution as I can get
for now.

But there are still a few probles I can see:
   - there is no way to "prefix" symbols within a unit, that I know of.
     Symbols may only be prefixed by the unit name directly. Is there a
     sort of a "namespace" in Pascal ?
   - if I make a wrapper unit around the third-party one, there is
     alredy little need for a prefix, since I can expose only the
     symbols I know of and that I use.
   - I find it even more tedious to do the same thing with the System
     unit or the standard Pascal units.

And then, if wrapper unit publicly uses the third-party unit, doesn't
that mean that all symbols 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-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Jorge Aldo G. de F. Junior
I am trying hard to think of a situation where unit prefixes are not
enough, but its hard to see.

2012/8/21 Timothy Madden <[hidden email]>:

> On 08/21/2012 02:17 PM, DaWorm wrote:
>> Very tedious, but you could create a wrapper unit and/or class for each
>> library, and expose a prefixed name instead of the original.
>
> Very ingeniuos, I believe this is as close to a solution as I can get
> for now.
>
> But there are still a few probles I can see:
>    - there is no way to "prefix" symbols within a unit, that I know of.
>      Symbols may only be prefixed by the unit name directly. Is there a
>      sort of a "namespace" in Pascal ?
>    - if I make a wrapper unit around the third-party one, there is
>      alredy little need for a prefix, since I can expose only the
>      symbols I know of and that I use.
>    - I find it even more tedious to do the same thing with the System
>      unit or the standard Pascal units.
>
> And then, if wrapper unit publicly uses the third-party unit, doesn't
> that mean that all symbols in the thrid-party unit are now automatically
> exposed and public in the wrapper unit ?

Nope, you can "uses" in the implementation section AND if a unit uses
a third unit, the third unit identifiers are not visible in the
program..

Unit a:
Interface
Uses b;
Implementation
End.

Unit b;
Interface
Type z=integer;
implementation
end.

program c;
uses a;
var
  h: z;
begin
end.

Type Z is not visible in program c, generating an error.

>
> 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-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Types, consts, variables, classes, functions, procedures etc, are
public if they are defined in the interface section, and private if
they are defined in the implementation section.

A unit/program imports the interface definitions of another unit if it
uses then in their own interface section.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Jorge Aldo G. de F. Junior
"With no error messages, or even with no changes to the program since 1
and a half year in the repository, the scientific calculations are now
all blown up, and program outputs only errors at runtime. The maintainer
now curses and chases me for having the nerve to leave a program
known as working in such a horrible mess in the repository."

Never tested, but doesnt the compiler warn of the colision ? if not, it should.

Usually i prefix my symbols with some meaningfull prefixes to avoid
collision. I never have two symbols with the same name and i hardly
used unit prefixes in the past.

But a collision warning from the compiler would be helpfull.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Marco van de Voort
In reply to this post by Timothy Madden
In our previous episode, Timothy Madden said:
> Very ingeniuos, I believe this is as close to a solution as I can get
> for now.
>
> But there are still a few probles I can see:
>    - there is no way to "prefix" symbols within a unit, that I know of.

Some languages related to pascal and maybe even other pascal dialects have
ways to import an unit/module qualified. FPC doesn't.

E.g. under modula2

IMPORT IO;

will import everything from IO qualified.

Unqualified importing is possible, but only for specific symbols:

FROM IO IMPORT WrStr;

allows to use WrStr without IO.

functions to be exported unqualified when imported.

E.g.

an

EXPORT UNQUALIFIED WrStr;

in module IO would cause the first statement to add WrStr both as "WrStr"
and IO.WrStr to the scope.


Note that FPC has other ways to disambiguate thoug. Since scope is stack
based in Wirthian languages, order of units in the uses clause matters for
which symbol is visible when similar named symbols clash.

>      Symbols may only be prefixed by the unit name directly. Is there a
>      sort of a "namespace" in Pascal ?

An unit/module is a concept that includes a namespace. (since you can
qualify identifiers with unitname)

>    - I find it even more tedious to do the same thing with the System
>      unit or the standard Pascal units.

Why do you feel the need for a prefix? The rare clashes can be easily dealt
with by uses list ordering and qualifying with unitname.

The only other thing I can imagine is that you might want to confine
importing units with gigantic numbers of symbols (like Windows) into general
units/modules, but confine that more OS specific and encapsulation units.

This because such units of course increase the chance of clashes
significantly, and while that can be remedied as above, in this case it is
better to avoid it.
 
> And then, if wrapper unit publicly uses the third-party unit, doesn't
> that mean that all symbols in the thrid-party unit are now automatically
> exposed and public in the wrapper unit ?

Not standard no. If you "uses" an unit you only import the symbols from
that unit itself, not what that unit imports.
 
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Sven Barth-2
In reply to this post by Jorge Aldo G. de F. Junior
Am 21.08.2012 14:10, schrieb Jorge Aldo G. de F. Junior:

> "With no error messages, or even with no changes to the program since 1
> and a half year in the repository, the scientific calculations are now
> all blown up, and program outputs only errors at runtime. The maintainer
> now curses and chases me for having the nerve to leave a program
> known as working in such a horrible mess in the repository."
>
> Never tested, but doesnt the compiler warn of the colision ? if not, it should.
>
> Usually i prefix my symbols with some meaningfull prefixes to avoid
> collision. I never have two symbols with the same name and i hardly
> used unit prefixes in the past.
>
> But a collision warning from the compiler would be helpfull.

Units provide a namespace, so UnitA.Foo is not the same as UnitB.Foo.
Thus it is perfectly allowed and valid and sometimes also common to have
a collision here. [also the compiler stops looking for further symbols
if it has found the first one => one of the reasons for the high
compilation speed]

Regards,
Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Jorge Aldo G. de F. Junior
I already know that you can fully qualify, i believe you misread my post.

Its not that common to have name colisions if you use prefixes like i said.

I cant see how the added complexity of full name space support would
help pascal in that regard.

2012/8/21 Sven Barth <[hidden email]>:

> Am 21.08.2012 14:10, schrieb Jorge Aldo G. de F. Junior:
>
>> "With no error messages, or even with no changes to the program since 1
>> and a half year in the repository, the scientific calculations are now
>> all blown up, and program outputs only errors at runtime. The maintainer
>> now curses and chases me for having the nerve to leave a program
>> known as working in such a horrible mess in the repository."
>>
>> Never tested, but doesnt the compiler warn of the colision ? if not, it
>> should.
>>
>> Usually i prefix my symbols with some meaningfull prefixes to avoid
>> collision. I never have two symbols with the same name and i hardly
>> used unit prefixes in the past.
>>
>> But a collision warning from the compiler would be helpfull.
>
>
> Units provide a namespace, so UnitA.Foo is not the same as UnitB.Foo. Thus
> it is perfectly allowed and valid and sometimes also common to have a
> collision here. [also the compiler stops looking for further symbols if it
> has found the first one => one of the reasons for the high compilation
> speed]
>
> Regards,
> Sven
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Sven Barth-2
Am 21.08.2012 15:13, schrieb Jorge Aldo G. de F. Junior:
> I already know that you can fully qualify, i believe you misread my post.
>
> Its not that common to have name colisions if you use prefixes like i said.
>
> I cant see how the added complexity of full name space support would
> help pascal in that regard.
>

I wrote about why the compiler does not and should not warn because of a
collision in naming of symbols in different units.

Regards,
Sven

> 2012/8/21 Sven Barth <[hidden email]>:
>> Am 21.08.2012 14:10, schrieb Jorge Aldo G. de F. Junior:
>>
>>> "With no error messages, or even with no changes to the program since 1
>>> and a half year in the repository, the scientific calculations are now
>>> all blown up, and program outputs only errors at runtime. The maintainer
>>> now curses and chases me for having the nerve to leave a program
>>> known as working in such a horrible mess in the repository."
>>>
>>> Never tested, but doesnt the compiler warn of the colision ? if not, it
>>> should.
>>>
>>> Usually i prefix my symbols with some meaningfull prefixes to avoid
>>> collision. I never have two symbols with the same name and i hardly
>>> used unit prefixes in the past.
>>>
>>> But a collision warning from the compiler would be helpfull.
>>
>>
>> Units provide a namespace, so UnitA.Foo is not the same as UnitB.Foo. Thus
>> it is perfectly allowed and valid and sometimes also common to have a
>> collision here. [also the compiler stops looking for further symbols if it
>> has found the first one => one of the reasons for the high compilation
>> speed]
>>
>> Regards,
>> Sven
>>
>>
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Marcos Douglas B. Santos
In reply to this post by Timothy Madden
On Mon, Aug 20, 2012 at 1:15 PM, Timothy Madden <[hidden email]> wrote:

> Hello
>
> As the language is currently specified, an identifier is searched in,
> and used from, the last unit in the USES clause that exposes that
> identifier.
>
> As some might know already, this exposes the user to future
> compatibility problems, stemming from the fact that the USES clause
> imports and "open namespace" into the user program.
>
> Imagine my perfectly tested scientific computations program uses two
> third-party units: Math and Trig. Currently only the Math unit exposes a
> log() function that computes the base e (that Euler number) logarithm of
> the given argument. All is so good and nice and I get promoted or I get
> to another project or to another company and leave the code on the
> repository.
>
> An year later a new version of Trig unit is available, the company
> promptly upgrades it and after some time someone else needs to make some
> changes to, or just re-compile for porting or other resons, the initial
> scietific computations program.
>
> Now Trig also exposes a new log() function, which computes the base 10
> logarithm for its given argument. Now Trig appears last in the USES
> list, after Math.
>
> With no error messages, or even with no changes to the program since 1
> and a half year in the repository, the scientific calculations are now
> all blown up, and program outputs only errors at runtime. The maintainer
> now curses and chases me for having the nerve to leave a program
> known as working in such a horrible mess in the repository.
>
> Of course this is a particular case, and in the general case it is most
> likely I will get some compilation error, if a unit that appears later
> in the USES clause suddenly now defines a previous symbol, that I make
> use of in my program. But still, if the program never changes (on
> git/svn/cvs), it should still compile later, as it stands...
>
> 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 to import from a different package until JDK 1.1.
> In this case is wasn't even a third-party library that triggered
> conflicts in existing code, it was the system run-time library. Since
> that story most Java programmers prefer to import and enumerate each and
> every class they use explicitly, instead of importing the package that
> provides the classes (I believe there is no equivalent feature in Pascal
> that imports only one symbol from a unit).
>
> 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 by some prefix I choose ?
>
> Something like:
>         import System into sys, Math, Trigonometric into trig;
> and then I would need to use trig.actg() as the only possible way to
> refer to actg() function in the Trigonometric unit, and to use
> Math.log() for logarithm ?
>
> Yes, I know I can qualify names even now if I so choose, but I was
> thinking for a way to ensure that qualified names are the only
> possibility, and a way that will allow me some shorter qualification,
> because with the current qualified names, the qualified name can be
> really long.
>
> Thank you,
> Timothy Madden

I feel your pain.
A long time ago this topic was talked here, on the list, and many
ideas were proposed... but none was accepted or because no one will
implement it.
I proposed this sintaxe:
uses my_long_unit_name as my;
begin
  my.proc();
end

Simple, clean and easy. But I do not know how implement this on the compiler.

IMHO, without changing the language, only the compiler could use
"simple names". All others  third-party library -- even Lazarus --
should use prefixes in ALL identifiers in the unit, unfortunately.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Timothy Madden
On 08/21/2012 06:06 PM, Marcos Douglas wrote:
> On Mon, Aug 20, 2012 at 1:15 PM, Timothy Madden <[hidden email]> 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 by some prefix I choose ?
>>
>> Something like:
>>         import System into sys, Math, Trigonometric into trig;
>> and then I would need to use trig.actg() as the only possible way to
>> refer to actg() function in the Trigonometric unit, and to use
>> Math.log() for logarithm ?
>>
>> Yes, I know I can qualify names even now if I so choose, but I was
>> thinking for a way to ensure that qualified names are the only
>> possibility, and a way that will allow me some shorter qualification,
>> because with the current qualified names, the qualified name can be
>> really long.
>>
>> Thank you,
>> Timothy Madden
>
> I feel your pain.
> A long time ago this topic was talked here, on the list, and many
> ideas were proposed... but none was accepted or because no one will
> implement it.
> I proposed this sintaxe:
> uses my_long_unit_name as my;
> begin
>   my.proc();
> end

This is what I am also looking for, I think it is the only real solution.

Also, with this syntax, qualifing the symbol with "my." is the only way
to access the proc() symbol there, meaning that
begin
   proc();
end
will never work.

Sorry to hear no one will implement it, you would not say it is
difficult to do at a first glance...

Thank you,
Timothy Madden

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Timothy Madden
In reply to this post by Jorge Aldo G. de F. Junior
On 08/21/2012 03:10 PM, Jorge Aldo G. de F. Junior wrote:
> "With no error messages, or even with no changes to the program since 1
> and a half year in the repository, the scientific calculations are now
> all blown up, and program outputs only errors at runtime. The maintainer
> now curses and chases me for having the nerve to leave a program
> known as working in such a horrible mess in the repository."
>
> Never tested, but doesnt the compiler warn of the colision ? if not, it should.

The problem is the language exposes my program to the risk of future
collisions from the units I use.

A warning is a little beyond the scope of this problem, because my
program is working perfectly as of now.

But next year, some unit I use will have reached a new version, and if I
merely recompile my program I have already have a conflict, that was not
there last year.

And the new version for the unit in question is fully compatible with
the old one, so you would say my code should still compile.

The question here is if it would be possible for the language to prevent
this problem, like python (and others) do.

Otherwise, I could never upgrade a library, even if the vendor announces
full compatibility with the previous version. Because I will still
expose my old code to the risk of new collisions.

Even worse, as the language currently stands, it is possible to upgrade
a unit to a compatible version and get a different behaviour from my
program. Without a single warning from the compiler.

Thank you,
Timothy Madden

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Marcos Douglas B. Santos
In reply to this post by Timothy Madden
On Tue, Aug 21, 2012 at 1:29 PM, Timothy Madden <[hidden email]> wrote:

> On 08/21/2012 06:06 PM, Marcos Douglas wrote:
>> On Mon, Aug 20, 2012 at 1:15 PM, Timothy Madden <[hidden email]> 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 by some prefix I choose ?
>>>
>>> Something like:
>>>         import System into sys, Math, Trigonometric into trig;
>>> and then I would need to use trig.actg() as the only possible way to
>>> refer to actg() function in the Trigonometric unit, and to use
>>> Math.log() for logarithm ?
>>>
>>> Yes, I know I can qualify names even now if I so choose, but I was
>>> thinking for a way to ensure that qualified names are the only
>>> possibility, and a way that will allow me some shorter qualification,
>>> because with the current qualified names, the qualified name can be
>>> really long.
>>>
>>> Thank you,
>>> Timothy Madden
>>
>> I feel your pain.
>> A long time ago this topic was talked here, on the list, and many
>> ideas were proposed... but none was accepted or because no one will
>> implement it.
>> I proposed this sintaxe:
>> uses my_long_unit_name as my;
>> begin
>>   my.proc();
>> end
>
> This is what I am also looking for, I think it is the only real solution.
>
> Also, with this syntax, qualifing the symbol with "my." is the only way
> to access the proc() symbol there, meaning that
> begin
>    proc();
> end
> will never work.

"Never work", hum... ,maybe a compiler directive to ON/OFF this
feature would be better.

> Sorry to hear no one will implement it, you would not say it is
> difficult to do at a first glance...

I think the FPC core did not like or does not care. If has no one to
implement it is a problem too. =(

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Marcos Douglas B. Santos
In reply to this post by Timothy Madden
On Tue, Aug 21, 2012 at 1:43 PM, Timothy Madden <[hidden email]> wrote:

> On 08/21/2012 03:10 PM, Jorge Aldo G. de F. Junior wrote:
>> "With no error messages, or even with no changes to the program since 1
>> and a half year in the repository, the scientific calculations are now
>> all blown up, and program outputs only errors at runtime. The maintainer
>> now curses and chases me for having the nerve to leave a program
>> known as working in such a horrible mess in the repository."
>>
>> Never tested, but doesnt the compiler warn of the colision ? if not, it should.
>
> The problem is the language exposes my program to the risk of future
> collisions from the units I use.

Yes.

> A warning is a little beyond the scope of this problem, because my
> program is working perfectly as of now.
>
> But next year, some unit I use will have reached a new version, and if I
> merely recompile my program I have already have a conflict, that was not
> there last year.

Yes.

> And the new version for the unit in question is fully compatible with
> the old one, so you would say my code should still compile.
>
> The question here is if it would be possible for the language to prevent
> this problem, like python (and others) do.

Obligatorily, not.
You can use a pratice to use unit.func always or, as I do, use a
prefix in all identifiers:
unit: foo_unitname
proc/func: fooProc, fooFunc  -- maybe use class procedure/function instead.
classes: TfooClass
global var: DO NOT USE!
global consts: FOO_CONST_NAME -- maybe use class const instead.

> Otherwise, I could never upgrade a library, even if the vendor announces
> full compatibility with the previous version. Because I will still
> expose my old code to the risk of new collisions.
>
> Even worse, as the language currently stands, it is possible to upgrade
> a unit to a compatible version and get a different behaviour from my
> program. Without a single warning from the compiler.

Yes, Yes, even people saying otherwise.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Mark Morgan Lloyd-5
In reply to this post by Timothy Madden
Timothy Madden wrote:

> But next year, some unit I use will have reached a new version, and if I
> merely recompile my program I have already have a conflict, that was not
> there last year.

I'd suggest that the first thing to do is to document in each unit what
version of the compiler it's tested with. It's only marginally more
difficult to add a warning (or even error) if the compiler version isn't
as expected.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Marco van de Voort
In reply to this post by Marcos Douglas B. Santos
In our previous episode, Marcos Douglas said:

> I proposed this sintaxe:
> uses my_long_unit_name as my;
> begin
>   my.proc();
> end

This doesn't protect any better, since
the new unit might also define "my".
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Marcos Douglas B. Santos
On Tue, Aug 21, 2012 at 3:08 PM, Marco van de Voort <[hidden email]> wrote:

> In our previous episode, Marcos Douglas said:
>
>> I proposed this sintaxe:
>> uses my_long_unit_name as my;
>> begin
>>   my.proc();
>> end
>
> This doesn't protect any better, since
> the new unit might also define "my".

True, but using this sintaxe I can use an alias to the third-party
units so, I can use my own names to reference identifiers that I can
not change.
The collision still can exists? Yes, but in that case the programmer
would be wrong, not third-party unit names or because the compiler not
helped.

The third-party could use a better and bigger name like "XyzNetSocket"
but I could use just "net" (uses XyzNetSocket as net), for example.

IMHO this is more sophisticated than pure namespace.

Marcos Douglas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to avoid namespace name clashes after USES ?

Jorge Aldo G. de F. Junior
Instead of implementing the half-assed C++ namespace model, just add
to the compiler a warning when it detects that there is a collision in
the current scope (two functions with the same parameters from
different units that can be called from the scope being inspected). I
believe function overload alread provides the necessary hooks, but i
cant do it because i have zero experience with FPC sources...

2012/8/21 Marcos Douglas <[hidden email]>:

> On Tue, Aug 21, 2012 at 3:08 PM, Marco van de Voort <[hidden email]> wrote:
>> In our previous episode, Marcos Douglas said:
>>
>>> I proposed this sintaxe:
>>> uses my_long_unit_name as my;
>>> begin
>>>   my.proc();
>>> end
>>
>> This doesn't protect any better, since
>> the new unit might also define "my".
>
> True, but using this sintaxe I can use an alias to the third-party
> units so, I can use my own names to reference identifiers that I can
> not change.
> The collision still can exists? Yes, but in that case the programmer
> would be wrong, not third-party unit names or because the compiler not
> helped.
>
> The third-party could use a better and bigger name like "XyzNetSocket"
> but I could use just "net" (uses XyzNetSocket as net), for example.
>
> IMHO this is more sophisticated than pure namespace.
>
> Marcos Douglas
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
123