Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
Am 2012-08-22 13:45, schrieb Lukasz Sokol: Recompilation when one of units/libraries was upgraded, almost always implies rebuild. Who on Earth is so trigger-happy to upgrade, rebuild and not test for regressions? This is the only sane way to get the process going - document it *as MML said below*; That's not the point. Why on earth should a programmer *not* get as much help as possible from a programming language/compiler? That's the genuine purpose of a programming language. Why stick with flaws if they are avoidable? *If* the issue Timothy reported can be avoided why *not* doing it? It would help avoiding many problems and reduce testing time. Although I have not such a strong feeling about it I would still appreciate the suggested addition. It would add a function for safer programming without drawbacks (except the coding effort of course). Though I don't know whether it can be implemented easily (if at all). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
Jürgen Hestermann wrote on Wed, 22 Aug 2012: Am 2012-08-22 13:45, schrieb Lukasz Sokol: Recompilation when one of units/libraries was upgraded, almost always implies rebuild. Who on Earth is so trigger-happy to upgrade, rebuild and not test for regressions? This is the only sane way to get the process going - document it *as MML said below*; That's not the point. Why on earth should a programmer *not* get as much help as possible from a programming language/compiler? That's the genuine purpose of a programming language. Indeed. Though I don't know whether it can be implemented easily (if at all). There are definitely some practical problems: * class/record helpers. The last class/record helper for a particular type that has come into scope automatically adds its methods to the helped class/record. If symbols can only be accessed by explicitly qualifying them with a separately specified unit alias, I don't see how you would activate class helpers from aliased units. Would these be an exception to the rule? Or would this require a new language construct to import all desired helper types explicitly? * Objective-Pascal categories are the same as class helpers, except that there an unlimited number of categories can be active for a single class at the same time. In the end, it's the same problem as above though. * Objective-Pascal also has the special id type. It is possible to call any method of any class type (and associated categories) in scope on a variable of this type. Again, I don't see a way how the proposed mechanism could be used to tell the compiler which classes it should search and which not if it should only search fully qualified identifiers from aliased units. There may be more issues, but these are the ones I can immediately think of. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
Am 22.08.2012 12:37, schrieb Timothy Madden: On 08/22/2012 09:57 AM, Marco van de Voort wrote: In our previous episode, Marcos Douglas said: [...] Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon 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, python uses that from the start. You must call os.path.basename(), and there is not way for you to call basename() directly (well, there is one, but they have taken special measures for it, so no name conflicts are possible). But for this to work, I need a way to alias the importing module, because not all units have a 2-letter name like os, for example I need something like: USES 'TrigonometricLibrary' AS 'trig' in 'pas/TrigonometricLibrary.pas' Of course I will not remove the existing behavior for USES, that is programmers can still say: USES charset, matrix, socket; and they get the behaviour they know. But if the programmer says: USES charset AS cs, matrix AS matrix, socket AS socket; than no symbols are made directly visible, and all of them need their prefix now (one of cs. or matrix. or socket. ). These prefixes are chosen by the programmer so thay may not create conflicts, as long as programmer sticks to the new form of USES. If both forms of USES are intermixed, like USES unit1, unit2, charset AS cs, matrix AS matrix, socket AS socket; than there is a chance that prefix cs will conflict with some unit1.cs symbol (either now or in a future version of unit1, or unit2). In this case I think it is appropriate to make the prefix cs., introduced by charset AS cs, to have precedence over unit1.cs. This is because the programmer must use the prefix cs. a lot in the program ((s)he has no choice, since the prefix is the only way to access simbols from unit charset). Feel free to extend the compiler with such a feature and provide a patch. If you give enough thought to it, provide enough tests and ensure that this won't influence old code too much the chances that your patch gets applied shouldn't be too bad. If you don't implement it... well... it may sound harsh, but: there are already many (partly more important) features that we need/want to implement... Note: I definitely prefer your solution instead of a warning ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On Wed, Aug 22, 2012 at 9:22 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: Jürgen Hestermann wrote on Wed, 22 Aug 2012: Am 2012-08-22 13:45, schrieb Lukasz Sokol: Recompilation when one of units/libraries was upgraded, almost always implies rebuild. Who on Earth is so trigger-happy to upgrade, rebuild and not test for regressions? This is the only sane way to get the process going - document it *as MML said below*; That's not the point. Why on earth should a programmer *not* get as much help as possible from a programming language/compiler? That's the genuine purpose of a programming language. Indeed. Though I don't know whether it can be implemented easily (if at all). There are definitely some practical problems: * class/record helpers. The last class/record helper for a particular type that has come into scope automatically adds its methods to the helped class/record. If symbols can only be accessed by explicitly qualifying them with a separately specified unit alias, I don't see how you would activate class helpers from aliased units. Would these be an exception to the rule? Or would this require a new language construct to import all desired helper types explicitly? * Objective-Pascal categories are the same as class helpers, except that there an unlimited number of categories can be active for a single class at the same time. In the end, it's the same problem as above though. * Objective-Pascal also has the special id type. It is possible to call any method of any class type (and associated categories) in scope on a variable of this type. Again, I don't see a way how the proposed mechanism could be used to tell the compiler which classes it should search and which not if it should only search fully qualified identifiers from aliased units. There may be more issues, but these are the ones I can immediately think of. At least you thought about it. :) Well, must be a solution, but this (new) feature should please everyone first, I think. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On Wed, Aug 22, 2012 at 11:05 AM, Sven Barth pascaldra...@googlemail.com wrote: Am 22.08.2012 12:37, schrieb Timothy Madden: On 08/22/2012 09:57 AM, Marco van de Voort wrote: In our previous episode, Marcos Douglas said: [...] Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon 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, python uses that from the start. You must call os.path.basename(), and there is not way for you to call basename() directly (well, there is one, but they have taken special measures for it, so no name conflicts are possible). But for this to work, I need a way to alias the importing module, because not all units have a 2-letter name like os, for example I need something like: USES 'TrigonometricLibrary' AS 'trig' in 'pas/TrigonometricLibrary.pas' Of course I will not remove the existing behavior for USES, that is programmers can still say: USES charset, matrix, socket; and they get the behaviour they know. But if the programmer says: USES charset AS cs, matrix AS matrix, socket AS socket; than no symbols are made directly visible, and all of them need their prefix now (one of cs. or matrix. or socket. ). These prefixes are chosen by the programmer so thay may not create conflicts, as long as programmer sticks to the new form of USES. If both forms of USES are intermixed, like USES unit1, unit2, charset AS cs, matrix AS matrix, socket AS socket; than there is a chance that prefix cs will conflict with some unit1.cs symbol (either now or in a future version of unit1, or unit2). In this case I think it is appropriate to make the prefix cs., introduced by charset AS cs, to have precedence over unit1.cs. This is because the programmer must use the prefix cs. a lot in the program ((s)he has no choice, since the prefix is the only way to access simbols from unit charset). Feel free to extend the compiler with such a feature and provide a patch. If you give enough thought to it, provide enough tests and ensure that this won't influence old code too much the chances that your patch gets applied shouldn't be too bad. I proposed this feature, a couple years ago, I said now again and got the same answer: Feel free to extend the compiler :( I never worked with compilers so, I'm not the programmer for that task, at first, sorry. If you don't implement it... well... it may sound harsh, but: there are already many (partly more important) features that we need/want to implement... Well, I will continue waiting a couple of year... :) Note: I definitely prefer your solution instead of a warning ;) Thanks. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
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 terminato...@gmail.com: 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 - fpc-pascal@lists.freepascal.org 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
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 pascaldra...@googlemail.com: 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
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 pascaldra...@googlemail.com: 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On Tue, Aug 21, 2012 at 1:29 PM, Timothy Madden terminato...@gmail.com wrote: On 08/21/2012 06:06 PM, Marcos Douglas wrote: On Mon, Aug 20, 2012 at 1:15 PM, Timothy Madden terminato...@gmail.com 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On Tue, Aug 21, 2012 at 1:43 PM, Timothy Madden terminato...@gmail.com 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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
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 - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to avoid namespace name clashes after USES ?
On Tue, Aug 21, 2012 at 10:23 PM, leledumbo leledumbo_c...@yahoo.co.id wrote: Requiring all functions to be allways fully qualified will make the most commom case worse than current implementation just to be better for the uncommon case. This is a step back, not forward... Indeed, and the way unit system works has an advantage: changing entry order / entry name in the uses clause can change the program behavior as intended without changing other parts. Say, I have GraphicsDirectX and GraphicsOpenGL unit, both having the same interface, simply changing this in the uses clause could do a backend switch easily. Yes, this is cool but you can got problems, as Timothy Madden said in this thread. I am not proposing break this feature -- because I use it too! -- but add one more. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
