Ideas for namespace implementation

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

Ideas for namespace implementation

Graeme Geldenhuys-2
Hi,

As I stated in another thread, namespaces are not perfect, but they do
work, and they do greatly reduce the chances for unitname or classname
conflicts. Other languages and frameworks (Java, .NET, C++ etc)
already showed this.

How visible is the unit name conflict problem?  Just think, how many
projects are there that use the unit names (or would like to use these
common names):
  constants.pas
  utils.pas
  etc...

Extremely common names, and are really good names for what they
contain, so why can't we use them in our projects? Namespaces will
resolve this problem. What we need to discuss, is how to implement
namespace support in FPC.

Some ideas I can think of... please list your own if you have some:

1)  Follow the "dotted" notation for unit names as implemented in Delphi.
   Cons:
     - They force rather long unit names, which is frowned upon in the Pascal
       community (for whatever reason).

   Ambiguities couldn't appear, but they are rather easy to overcome
   with a simple language rule. Object Pascal already have many language
   rules, this will just be a new one.
   See the following Mantis report for details:
      http://bugs.freepascal.org/view.php?id=14439


2) Another idea is in a way similar to how compiler defines work. This
idea tries
    to resolve the problem in (1) with long unit names and with least amount of
    resistance to existing code. A namespace can be applied
    to a single unit, or to a group of units (think of it as a
"package"). To get this to
    work, we will have to introduce a new keyword and a new compiler parameter.
    Here follows examples of both.

    // per unit
   unit utils namespace companyxyz;
   uses
     ...
   end.

    ... or applied at compile time to all units being compiled.

    // our sample unit - as normal, nothing new
    unit utils;
    uses
      ...
    end.

    $ fpc -namespace=companyxyz utils.pas constants.pas ...

    ... if a conflict occurs, then you reference the unit with the
full namespace.
    eg:

      uses
         companyxyz.utils;  // because unit names must be valid
identifier and thus,
                                      // can't contain dots, when the
compiler sees this, it knows
                                      // companyxyz. is a namespace reference.

    Pros:
      - No long unit names are required.
      - We can use all the easy unit names for projects. eg:
utils.pas, constans.pas etc.
      - Can be applied to existing code without any code changes, simply by
        adding a new namespace compiler parameter when compiling that existing
        code. Thus, FPC's RTL and FCL, or fpGUI or Lazarus etc could
apply it too, to
        their makefiles.
      - referencing via a namespace is only needed when a conflict occurs, other
        than that, units are used as normal.
      - If no namespace is specified, then it automatically falls
under the "global"
        namespace - maybe using the namespace value "global" and will be similar
        to all units containing the following:
        eg:
            unit myunit namespace global;
            ...
            end.

            ... or being compiled with 'fpc -namespace=global <units>'


3)  Automatically add the directory where the unit is located, as the
namespace. Similar to what Java does.



I'm sure given more time, I could come up with some more ideas, but I
rather like (2) because it could be applied to all existing code,
without any code changes required.



--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for namespace implementation

Graeme Geldenhuys-2
On 25 July 2010 19:16, Michael Van Canneyt wrote:
>
> What unit name conflicts ? In 15 years that I work with Delphi and FPC, and
> I have use many many packages, I encountered exactly 1 conflict:

Then you are extremely lucky. I have experience stacks of unit name
conflicts in my years of programming. Have you never had the urge to
use the unit name: constants.pas? utils.pas?



> the strutils of rxlib, which conflicted with strutils introduced in a later
> version of Delphi. The RX copy was renamed to rxstrutils, and that was it.

A perfect example of the problem!
  * Compilers get preference over the easy and well descibed unit
names, while other projects must now rename there units.
  * Other projects now have to live with crappy named units with ugly prefixes.
  * can't use underscores because for some reason it is frowned appon,
so now you
    get odd looking units where the prefix ends with the same letter
as the original unit names.

Utilities functions that work on Strings - wouldn't it make sense to
have them in a unit: strutils.pas?
Currently we can't, even though the unit name perfectly describes the
function of that unit - so we have to shun from the ideal name. If we
don't, we are guaranteed to get conflicts in our projects. So now only
the "compiler" projects like Delphi or FPC my use such names - that is
crap.


> I am sorry, but I think that the seriousness of the problem is very much
> overestimated. Wanting to type rx.strutils versus rxstrutils. Really ?

And my suggestion (2) will reduce such syntax *only* when a conflict
has occured, without long unit names.


> And let us not forget: most component vendors must support older versions of
> Delphi, so they are barred from using the dotted unit name syntax anyway.

Which option (2) I suggested will also handle via a namespace compiler
parameter or the 'namespace <value>' in the unit, but declared inside
a IFDEF checking for compiler version: eg

unit utils {$IFDEF Ver2_4_x} namespace myproject {$ENDIF};
uses
  ...
end.


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: Ideas for namespace implementation

Michael Van Canneyt


On Sun, 25 Jul 2010, Graeme Geldenhuys wrote:

> On 25 July 2010 19:16, Michael Van Canneyt wrote:
>>
>> What unit name conflicts ? In 15 years that I work with Delphi and FPC, and
>> I have use many many packages, I encountered exactly 1 conflict:
>
> Then you are extremely lucky. I have experience stacks of unit name
> conflicts in my years of programming. Have you never had the urge to
> use the unit name: constants.pas? utils.pas?
>

No. Because I don't see the difference between having to type

uses
   wisa.utils;

versus

uses wisautils;

The latter is even shorter. So I really don't see the gain.

The discussion is not about namespaces. Object Pascal HAS namespaces,
namely units. The discussion is about 'enhancing' the namespace to allow
one or more dots in the name.

That said, I don't really care whether the . ends up in the compiler or not,
but I do think it is much ado about nothing. Yes, it may be nice to have,
but no, it is not urgent and not the end of the world if we don't do it.

Unicode strings is orders of magnitude more important.

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

Re: Re: Ideas for namespace implementation

Graeme Geldenhuys-2
On 25 July 2010 23:30, Michael Van Canneyt wrote:
>
> The discussion is not about namespaces. Object Pascal HAS namespaces,
> namely units. The discussion is about 'enhancing' the namespace to allow one
> or more dots in the name.

With the importance that the '.' is only needed when resolving a
conflict - all other instances, you will just use the unit name as
normal. Also, the '.' usage is only limited to the uses clause. At
least we will be able to easily use more logical unit names without
the fear of getting unit name conflicts.


> Unicode strings is orders of magnitude more important.

I wasn't arguing what is/isn't more important that other tasks. I'm
gathering information and feedback on a feature request to enhance
namespace support to reduce unit name conflicts. Just because Unicode
strings haven't been implemented yet, doesn't mean we maybe implement
something else.

Regarding the cpstrnew branch:
I'll try and resolve my Unicode String branch (cpstrnew) compilation
issues this coming week (or at least report the issue with more
details). Since the resync with Trunc, I can't compile that branch,
and thus can't submit my local changes I have so far.


--
Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Ideas for namespace implementation

Sven Barth-2
In reply to this post by Graeme Geldenhuys-2
Hi!

I personally don't have a real opinion pro or against extended
namespace, so I'll try to answer as neutral as possible.

Am 25.07.2010 19:45, schrieb Graeme Geldenhuys:

> 1)  Follow the "dotted" notation for unit names as implemented in Delphi.
>     (...)
>
>
> 2) Another idea is in a way similar to how compiler defines work. This
> idea tries
>      to resolve the problem in (1) with long unit names and with least amount of
>      resistance to existing code. A namespace can be applied
>      to a single unit, or to a group of units (think of it as a
> "package"). To get this to
>      work, we will have to introduce a new keyword and a new compiler parameter.
>      Here follows examples of both.
>
>      // per unit
>     unit utils namespace companyxyz;
>     uses
>       ...
>     end.
>
>      ... or applied at compile time to all units being compiled.
>
>      // our sample unit - as normal, nothing new
>      unit utils;
>      uses
>        ...
>      end.
>
>      $ fpc -namespace=companyxyz utils.pas constants.pas ...
>
>      ... if a conflict occurs, then you reference the unit with the
> full namespace.
>      eg:
>
>        uses
>           companyxyz.utils;  // because unit names must be valid
> identifier and thus,
>                                        // can't contain dots, when the
> compiler sees this, it knows
>                                        // companyxyz. is a namespace reference.
>(...)
>
> 3)  Automatically add the directory where the unit is located, as the
> namespace. Similar to what Java does.
>

Regarding your ideas 2 and 3: as they are not Delphi compatible they
might be considered a "bad thing" (TM) by the FPC developers.

The problems of all three (or maybe all namespace ideas) is that they
aren't compatible to older versions of Delphi (and FPC). Even if your
second idea including compiler version checks is used, you'd be back at
the start, because now you'd have a conflicting unit name.

Example:
I'll take the strutils example from rxlib:

unit strutils {$ifdef ver2_6_0}namespace rx{$endif};
(...)

So now we use a 2.4.0 compiler or a Delphi compiler and have a problem:
How can I use the strutils from FPC/Delphi from a unit that uses
strutils from rxlib?

The only solution to this might be

{$ifdef ver2_6_0}
unit strutils namespace rx;
{$else}
unit rxstrutils;
{$endif}

But now it gets ugly regarding uses-Clauses in rxlib itself and units
that use rxlib. :(

Regarding your idea 3:

As FPC can use different directories for the search paths how would you
solve similar hierarchies?
Or a different problem: the source units of FCL packages reside in
packages/$PackageName/src/ while the compiled units are in
units/$Target/$PackageName/. What namespace should apply here?
Where is the base of the namespace? Is it the FPC base dir? What about
units that aren't part of FPC, like fpGUI?

Your idea 3 might become the most complicated one, because of the search
path features that FPC has in comparison to Java.


If I'd have to choose one of your three ideas I'd choose the second one
although it has some backwards-compatibility problems. But there still
might be better ideas out there. :)

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

Re: Ideas for namespace implementation

Graeme Geldenhuys-2
Op 2010-07-26 10:14, Sven Barth het geskryf:
>
> Regarding your ideas 2 and 3: as they are not Delphi compatible they
> might be considered a "bad thing" (TM) by the FPC developers.

Currently FPC developers do not want to implement the "dotted" namespace
idea from Delphi - though they already stated there stance on Delphi
compatibly regarding this. In short - Delphi in-compatibility is not a
problem here, just like Generics or Compiler Modes or ..... FPC doesn't do
everything like Delphi, sometimes it does things _better_ than Delphi. FPC
Namespaces would hopefully fall under the latter.


> The problems of all three (or maybe all namespace ideas) is that they
> aren't compatible to older versions of Delphi (and FPC).

I don't see this as a problem at all.

  * Currently they have unit name conflicts. No solution other than
    renaming the offending unit. Even if they introduced the "dotted"
    namespace idea from Delphi, it is not supported by FPC, so you
    still sit with a problem. You are forced to rename the unit. See
    the RxLib example.

  * Simply upgrade your FPC to a newer version. FPC is FREE. You don't
    have the burden of Delphi upgrade costs. FPC development is open,
    so you can prepare your code as you see things change in FPC, so
    that when a new version comes out, you already are compatible with
    it (again unlike Delphi - remember Unicode support in Delphi. Users
    had no warning of its syntax and required changes until AFTER Delphi
    was released.).


> Regarding your idea 3:
> As FPC can use different directories for the search paths how would you
> solve similar hierarchies?

Idea 3 is crap - I see lots of issues too, but thought I would mention it
simply because that is what JAVA uses.



Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

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

Re: Ideas for namespace implementation

Sven Barth-2
Hi!

Am 26.07.2010 10:40, schrieb Graeme Geldenhuys:

> Op 2010-07-26 10:14, Sven Barth het geskryf:
>>
>> Regarding your ideas 2 and 3: as they are not Delphi compatible they
>> might be considered a "bad thing" (TM) by the FPC developers.
>
> Currently FPC developers do not want to implement the "dotted" namespace
> idea from Delphi - though they already stated there stance on Delphi
> compatibly regarding this. In short - Delphi in-compatibility is not a
> problem here, just like Generics or Compiler Modes or ..... FPC doesn't do
> everything like Delphi, sometimes it does things _better_ than Delphi. FPC
> Namespaces would hopefully fall under the latter.
>

I hope this, too. And personally I am not interested in Delphi
compatibility because I only use Delphi (6) at work and there we use a
stable set of compatible components. And the few times I used units from
FPC to achieve something (TProcess, SQLite interface unit) I was able to
adjust them to the Delphi compiler.

>
>> The problems of all three (or maybe all namespace ideas) is that they
>> aren't compatible to older versions of Delphi (and FPC).
>
> I don't see this as a problem at all.
>
>    * Currently they have unit name conflicts. No solution other than
>      renaming the offending unit. Even if they introduced the "dotted"
>      namespace idea from Delphi, it is not supported by FPC, so you
>      still sit with a problem. You are forced to rename the unit. See
>      the RxLib example.
>
>    * Simply upgrade your FPC to a newer version. FPC is FREE. You don't
>      have the burden of Delphi upgrade costs. FPC development is open,
>      so you can prepare your code as you see things change in FPC, so
>      that when a new version comes out, you already are compatible with
>      it (again unlike Delphi - remember Unicode support in Delphi. Users
>      had no warning of its syntax and required changes until AFTER Delphi
>      was released.).
>

Yes, FPC is free and examples where an older version of FPC is needed
can only be constructed artificially, but the Delphi case still holds.
E.g. tiOPF supports Delphi besides FPC.
I don't know the unit structure of tiOPF but suppose you have a unit
"utils" that once conflicted with a Delphi unit and was renamed to eg.
"tioutils".
Now FPC introduces the new namespace system and you'd like to jump the
train and make tiopf "namespace aware". Now you rename the "tioutils"
unit again to "utils" and set the prefix to "tiopf". Now you've upset
the Delphi users in two different ways:
1) They need to change their uses clauses
2) Now the unit conflicts again with a Delphi provided "utils" unit
(does Delphi have a "utils" unit? it's an example after all...)

Or would you keep the "tioutils" unit name and just introduce the
namespace? But what did you gain then?

So... what is your suggestion for such packages providers to solve the
problem?

Please note again: I'm not against this "unit Foo namespace Bar" idea
and the more I think about it the more I like it, but I also tend to see
problems that arise because of such a feature and to discuss solutions
for such problems.

>> Regarding your idea 3:
>> As FPC can use different directories for the search paths how would you
>> solve similar hierarchies?
>
> Idea 3 is crap - I see lots of issues too, but thought I would mention it
> simply because that is what JAVA uses.
>

I didn't want to say it that directly ^^

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

Re: Re: Ideas for namespace implementation

Michael Van Canneyt
In reply to this post by Graeme Geldenhuys-2


On Sun, 25 Jul 2010, Graeme Geldenhuys wrote:

> On 25 July 2010 23:30, Michael Van Canneyt wrote:
>>
>> The discussion is not about namespaces. Object Pascal HAS namespaces,
>> namely units. The discussion is about 'enhancing' the namespace to allow one
>> or more dots in the name.
>
> With the importance that the '.' is only needed when resolving a
> conflict - all other instances, you will just use the unit name as
> normal. Also, the '.' usage is only limited to the uses clause. At
> least we will be able to easily use more logical unit names without
> the fear of getting unit name conflicts.

Well, I fail to see what is more logical in my.constants than in myconstants.
The unit is still called my.constants, not constants. So you'll end up
typing my.constants everywhere anyway. The gain of this over myconstants is
highly debatable.

Since (as jonas points out) it introduces an ambiguity and violates the rule
that a unit name must be a pascal identifier, the pros must be weighed against
the contras. The contras are known.

The only pro argument that carries any weight is Delphi compatibility.
All the rest is a matter of personal opinion.

Given that, I suspect that if someone supplied a patch that allows dotted
unit names *in delphi mode* (with matching resolving algorithm), it would
not be rejected. But I also wouldn't hold my breath waiting for one of
the core developers to implement it. Clearly, none of them sees the need for
it, at least that should have become obvious from the thread.

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

Re: Re: Ideas for namespace implementation

Graeme Geldenhuys-2
Op 2010-07-26 11:34, Michael Van Canneyt het geskryf:
>
> Well, I fail to see what is more logical in my.constants than in myconstants.
> The unit is still called my.constants, not constants. So you'll end up
> typing my.constants everywhere anyway. The gain of this over myconstants is
> highly debatable.
>
> Since (as jonas points out) it introduces an ambiguity and violates the rule
> that a unit name must be a pascal identifier, the pros must be weighed against
> the contras. The contras are known.

You are confusing the point. (excuse the pun) :)

My preferred namespaces implementation is *not* the dotted unit names like
Delphi currently have. My preferred method (see my other message thread)
would be a 'namespace' keyword and a new -namepace= compiler parameter.
Unit names will stay the same as the currently are - a legal identifier
without the use of extra dots in the unit name.

In my opinion, this is a much better idea than what Delphi implemented.

Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

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

Re: Ideas for namespace implementation

Graeme Geldenhuys-2
In reply to this post by Sven Barth-2
Op 2010-07-26 11:18, Sven Barth het geskryf:
> Yes, FPC is free and examples where an older version of FPC is needed
> can only be constructed artificially, but the Delphi case still holds.
> E.g. tiOPF supports Delphi besides FPC.
> I don't know the unit structure of tiOPF but suppose you have a unit
> "utils" that once conflicted with a Delphi unit and was renamed to eg.
> "tioutils".


In the case of tiOPF, it already prefixes all units with 'ti' and all
classes with 'Tti'. The same as what fpGUI does. This reduces the chances
of conflicts, so such code can stay the same, especially if that code is
used both under Delphi and FPC.

My suggestion of namespaces is purely for FPC and FPC compatible code -
*not* Delphi. Why, because Delphi namespace support already exists, and
will not be implemented as such in FPC. So lets leave cross-compiler
projects out of the discussion, because they are a "special" case with
different rules.


> Now FPC introduces the new namespace system and you'd like to jump the
> train and make tiopf "namespace aware". Now you rename the "tioutils"
> unit again to "utils" and set the prefix to "tiopf".

For FPC only projects, that would be fine with me, and those projects would
make a final release before the unit name change (for users that want
compatibility without namespaces support). Any future development can then
take advantage of namespaces and more logical unit names without ugly prefixes.

Just to show how ugly unit names look with prefixes.
eg:
  tiUtils.pas   vs   tiutils.pas     vs     utils.pas

Under OSes that have filesystems that are case sensitive (like under
Linux), the norm is to use lowercase filenames. But with prefixes, it makes
such unit names hard to read, and mixing cases make unit names inconsistent
and prone to errors. Whereas, if you where free to use a simple unit name
without prefixes, you get easy to read and consistent lowercase names.

Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

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

Re: Ideas for namespace implementation

Anthony Walter-3
In reply to this post by Graeme Geldenhuys-2
On Mon, Jul 26, 2010 at 4:40 AM, Graeme Geldenhuys <[hidden email]> wrote:
In short - Delphi in-compatibility is not a
problem here, just like Generics or Compiler Modes or ..... FPC doesn't do
everything like Delphi, sometimes it does things _better_ than Delphi. FPC
Namespaces would hopefully fall under the latter.

I'd say that the way FPC handles things different than Delphi in some cases is worse. Take generics, which you mentioned.

type
  generic TSomething<T> = class

is worse than

type
  TSomething<T> = class

The only reason I can see having put the word "generic" in front of the identifier, something which Pascal has never done (put keywords in front of identifiers when declaring types), was to make it easier for the compiler author. That is to say, negate the need to look ahead.

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

Re: Ideas for namespace implementation

Reimar Grabowski
In reply to this post by Graeme Geldenhuys-2
On Mon, 26 Jul 2010 12:14:26 +0200
Graeme Geldenhuys <[hidden email]> wrote:

> Just to show how ugly unit names look with prefixes.
> eg:
>   tiUtils.pas   vs   tiutils.pas     vs     utils.pas

Is this really a problem that warrants time to develop and test a solution?
Two letters?
Well, it is your time after all.
So I vote for the solution that is the least intrusive, meaning that I don't have to change my code much or at all.

Thanks
R.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: Ideas for namespace implementation

Martin Friebe
In reply to this post by Graeme Geldenhuys-2
On 25/07/2010 22:53, Graeme Geldenhuys wrote:

> On 25 July 2010 23:30, Michael Van Canneyt wrote:
>    
>> The discussion is not about namespaces. Object Pascal HAS namespaces,
>> namely units. The discussion is about 'enhancing' the namespace to allow one
>> or more dots in the name.
>>      
> With the importance that the '.' is only needed when resolving a
> conflict - all other instances, you will just use the unit name as
> normal. Also, the '.' usage is only limited to the uses clause. At
> least we will be able to easily use more logical unit names without
> the fear of getting unit name conflicts.
>    
Let me see, if I got the idea (Graeme's idea) correct.

lets say we have:
rtl:   classes, sysutils,  but *not* foo
rxlib:   sysutils, foo    (all in namespace rx)
mylib:   foo   (namespace my)
It the my project itself:   sysutils, my   (no namespace?)

uses classes;    // the one from rtl
uses sysutils;    // the one from my project?
uses rtl.sysutols;   // rtl
uses foo;  // error ambigious?
uses rx.foo;  // rxlib

Am I correct so far, that his is the plan?

uses rc.foo, my.foo, my; // there is a unit my
...
begin
   foo.a; // error, which foo?
   my.foo.a; // is that unit my, record foo.a OR unit my.foo ?

----------
But worst of all
uses sysutils;    // the one from my project?

Now if any one else is to read/review/... the code => they will not be
aware of sysutils not being rtl.
In order to keep it human understandable, the unt name "sysutils"
(unqualified) must only be allowed to refer to exactly one unit => the
one from the rtl, no other one ever.

----------
even:
uses rs.sysutils
...
begin
sysutils.a; // againg, it is "sysutils" onlt, any reader should be
correct to think it is from the rtl and the rtl only

if sysutils ever refers to anything but the rtl, it will (highly)
obfuscate the code.

----------
or "foo" in the above example.

let's say it wasn't part of rx. And my project uses the packages rx and
my. then
uses foo; // from package my, since it only exists there.

Nor rx is updated, and suddenly contains a unit called "foo" => and all
code breaks
Well it would break without namespaces too, but still namespaces hasn't
helped avoiding the breakage.

Yes, maybe in this case namespaces can help fixing the breakage, but at
the cost of code obfuscation...






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

Re: Ideas for namespace implementation

Graeme Geldenhuys-2
In reply to this post by Graeme Geldenhuys-2
Hi,

I created a wiki page for this to consolidate ideas.

  http://wiki.freepascal.org/Namespaces


Regards,
  - Graeme -

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

Re: Re: Ideas for namespace implementation

Graeme Geldenhuys-2
In reply to this post by Martin Friebe
Op 2010-07-26 14:34, Martin het geskryf:
> Let me see, if I got the idea (Graeme's idea) correct.

Please note: I did not say my ideas are perfect, just that they are
suggestions that was put out there. Discussions regarding namespaces and
ideas/suggestions need to filter out the finer details of what could or
couldn't work. This is the whole point of this discussion at this stage.


> lets say we have:
> rtl:   classes, sysutils,  but *not* foo
> rxlib:   sysutils, foo    (all in namespace rx)
> mylib:   foo   (namespace my)
> It the my project itself:   sysutils, my   (no namespace?)
>
> uses classes;    // the one from rtl
> uses sysutils;    // the one from my project?

No. I envision that not defining a namespace means if falls under the
"global" namespace, and the global namespace takes priority. So with saying
that, FPC's RTL would probably be compiled as-is without defining any
namespace, giving it search priority.

In your example above, sysutils inside the project conflicts with the
sysutils of the rtl, so the project will have to define a namespace for its
sysutils unit. eg: 'unit sysutils namespace myproject;' or compile the
project with a namespace compiler parameter.

> uses rtl.sysutols;   // rtl

As I mentioned above. Reducing the amount of required changes (which would
make FPC developers happy), means that the RTL is not compiled with any
namespace, so to reference the RTL's Sysutils unit, you would simply use:
  uses
    sysutils;


> uses foo;  // error ambigious?

Yes, just like you would get with the current FPC compiler (which doesn't
have namespace support). You need to specify which namespace the 'foo' unit
belongs too. Neither the RTL nor the project contains a 'foo' unit, so the
compiler will give a conflicting unitname error (or something like that).



> uses rc.foo, my.foo, my; // there is a unit my
> ...
> begin
>    foo.a; // error, which foo?
>    my.foo.a; // is that unit my, record foo.a OR unit my.foo ?

Good point, I haven't thought that far. I only worked though of the uses
clause.  Maybe when referencing a namespace we need a different syntax?
Something that distinguishes between a <unit name>.<var or record>
reference and a <namespace>.<unit name> reference.

I'm not sure what will fit nicely in the Object Pascal language. Generics
already uses the < and >  characters. The _ is not allowed as the starting
character of a unit name, so maybe that could be used? Or maybe the #
character?

eg:
  uses
    rc.foo, my.foo, my;
  ...
  begin
    foo.a;  // is the <unitname>.<var or record> syntax
    _my.foo.a; // is <namespace>.<unit name>.<var or record> syntax.

...not sure if _ should be used in the uses clause as well for consistency.
Currently a '.' (dotted) unit name is not allowed in the uses clauses, so
FPC could know that a 'rc.foo' means <namespace>.<unit>. But consistent
syntax is probably better, so the uses clause will change to.

  uses
    _rc.foo, _my.foo, my;

Second suggestion is changing the _ character to a # character, but then
again, that conflicts with a hex char notation, so is probably not a good idea.


> But worst of all
> uses sysutils;    // the one from my project?

No, because the RTL is not compiled with a namespace, so falls under the
"global" namespace with takes preference over project units or all other
namespaces. This then stays consistent with how developers understood the
code as it currently works. Compiler included units take preference.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

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

Re: Re: Ideas for namespace implementation

Martin Friebe
On 26/07/2010 14:44, Graeme Geldenhuys wrote:
> Please note: I did not say my ideas are perfect, just that they are
> suggestions that was put out there. Discussions regarding namespaces and
> ideas/suggestions need to filter out the finer details of what could or
> couldn't work. This is the whole point of this discussion at this stage.
>    
Which is why I add examples, and question, instead of saying "I dislike
it, simply because I wish to annoy you" ;>

SCNR

>> lets say we have:
>> rtl:   classes, sysutils,  but *not* foo
>> rxlib:   sysutils, foo    (all in namespace rx)
>> mylib:   foo   (namespace my)
>> It the my project itself:   sysutils, my   (no namespace?)
>>
>> uses classes;    // the one from rtl
>> uses sysutils;    // the one from my project?
>>      
...
> In your example above, sysutils inside the project conflicts with the
> sysutils of the rtl, so the project will have to define a namespace for its
> sysutils
>    
ok

>> uses rc.foo, my.foo, my; // there is a unit my
>> ...
>> begin
>>     foo.a; // error, which foo?
>>     my.foo.a; // is that unit my, record foo.a OR unit my.foo ?
>>      
> Good point, I haven't thought that far.
It's from the mantis issue, that you quoted...

> I only worked though of the uses
> clause.  Maybe when referencing a namespace we need a different syntax?
> Something that distinguishes between a<unit name>.<var or record>
> reference and a<namespace>.<unit name>  reference.
>
> I'm not sure what will fit nicely in the Object Pascal language. Generics
> already uses the<  and>   characters. The _ is not allowed as the starting
> character of a unit name, so maybe that could be used? Or maybe the #
> character?
>
> eg:
>    uses
>      rc.foo, my.foo, my;
>    ...
>    begin
>      foo.a;  // is the<unitname>.<var or record>  syntax
>      _my.foo.a; // is<namespace>.<unit name>.<var or record>  syntax.
>    
Devil's advocate: Why not using the "_" as separator:
   my_foo.a  // a in my_foo
   my.foo.a; // record foo int my

> ...not sure if _ should be used in the uses clause as well for consistency.
> Currently a '.' (dotted) unit name is not allowed in the uses clauses, so
> FPC could know that a 'rc.foo' means<namespace>.<unit>. But consistent
> syntax is probably better, so the uses clause will change to.
>
>    uses
>      _rc.foo, _my.foo, my;
>
> Second suggestion is changing the _ character to a # character, but then
> again, that conflicts with a hex char notation, so is probably not a good idea.
>    
I do not think, that prefixing namespace identifers (# or _) is a good
idea at all. If anything like this, then use a diff separator

my#foo.a // namespace
my.foo.a // record

# is used for chars (hex is #$) => #foo can ot be a char....

So technically possible, but IMHO messy, very messy

>> But worst of all
>> uses sysutils;    // the one from my project?
>>      
> No, because the RTL is not compiled with a namespace, so falls under the
> "global" namespace with takes preference over project units or all other
> namespaces. This then stays consistent with how developers understood the
> code as it currently works. Compiler included units take preference.
>    
You missed the important bit of this section.

let's correct the uses:

uses myspace.sysutils;
  // and only this sysutils, not using the global rtl.sysutils at all
....
begin
   SysUtils.Exception;

Now if any one else is to read/review/... the code => they will not be
aware of sysutils not being rtl.
They will assume that "SysUtils.Exception" is "RTL.SysUtils.Exception",
but it really is "myspace.SysUtils.Exception"

For me,. that is code obfuscation. In order to keep it human
understandable, the unt name "sysutils" (unqualified) must only be
allowed to refer to exactly one unit => the one from the rtl, no other
one ever.

But if we allow the unqualified to only refer to the original rtl one =>
then all other SysUtils must be fully qualified at any occurence they
have (even if they are the only SysUtils used in that unit).
And if the always need full qualification, then they do not differ from
a prefix (the dot becomes part of the unti name).

Martin




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

Re: Re: Ideas for namespace implementation

Sven Barth-2
In reply to this post by Graeme Geldenhuys-2
Hi!

On 26.07.2010 15:44, Graeme Geldenhuys wrote:

>> uses rc.foo, my.foo, my; // there is a unit my
>> ...
>> begin
>>     foo.a; // error, which foo?
>>     my.foo.a; // is that unit my, record foo.a OR unit my.foo ?
>
> Good point, I haven't thought that far. I only worked though of the uses
> clause.  Maybe when referencing a namespace we need a different syntax?
> Something that distinguishes between a<unit name>.<var or record>
> reference and a<namespace>.<unit name>  reference.
>
> I'm not sure what will fit nicely in the Object Pascal language. Generics
> already uses the<  and>   characters. The _ is not allowed as the starting
> character of a unit name, so maybe that could be used? Or maybe the #
> character?

Are you sure that "_" is not allowed at the beginning of a unit name?

=== source start ===
unit _test;

interface

implementation

end.
=== source end ===

Compiles without problems.

>
> eg:
>    uses
>      rc.foo, my.foo, my;
>    ...
>    begin
>      foo.a;  // is the<unitname>.<var or record>  syntax
>      _my.foo.a; // is<namespace>.<unit name>.<var or record>  syntax.
>
> ...not sure if _ should be used in the uses clause as well for consistency.
> Currently a '.' (dotted) unit name is not allowed in the uses clauses, so
> FPC could know that a 'rc.foo' means<namespace>.<unit>. But consistent
> syntax is probably better, so the uses clause will change to.
>
>    uses
>      _rc.foo, _my.foo, my;
>
> Second suggestion is changing the _ character to a # character, but then
> again, that conflicts with a hex char notation, so is probably not a good idea.
>
>

What about using ":" as a starting character for namespaces? It should
be less problematic than "#" (even when used in type/variable/parameter
declarations).
Other possibilities are "!", "?", "~", "%", "|", "\" and """ as they
aren't used yet as far as I'm aware of... (please correct me here if
necessary ^^)

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

Re: Re: Ideas for namespace implementation

Sven Barth-2
In reply to this post by Martin Friebe
Hi!

On 26.07.2010 16:06, Martin wrote:

>>> But worst of all
>>> uses sysutils; // the one from my project?
>> No, because the RTL is not compiled with a namespace, so falls under the
>> "global" namespace with takes preference over project units or all other
>> namespaces. This then stays consistent with how developers understood the
>> code as it currently works. Compiler included units take preference.
> You missed the important bit of this section.
>
> let's correct the uses:
>
> uses myspace.sysutils;
> // and only this sysutils, not using the global rtl.sysutils at all
> ....
> begin
> SysUtils.Exception;
>
> Now if any one else is to read/review/... the code => they will not be
> aware of sysutils not being rtl.
> They will assume that "SysUtils.Exception" is "RTL.SysUtils.Exception",
> but it really is "myspace.SysUtils.Exception"
>
> For me,. that is code obfuscation. In order to keep it human
> understandable, the unt name "sysutils" (unqualified) must only be
> allowed to refer to exactly one unit => the one from the rtl, no other
> one ever.
>
> But if we allow the unqualified to only refer to the original rtl one =>
> then all other SysUtils must be fully qualified at any occurence they
> have (even if they are the only SysUtils used in that unit).
> And if the always need full qualification, then they do not differ from
> a prefix (the dot becomes part of the unti name).

What about that the compiler enforces that you use the fully qualified
name if you used it in the uses?

e.g.

uses
   myspace.sysutils; // this sysutils contains an identifier "Exception"

begin
   Exception; // no error
   SysUtils.Exception; // identifier not found
   MySpace.SysUtils.Exception; // no error
end.

So the declaration of "myspace.sysutils" declares a new
pseude-identifier. By using a different separator or prefix this could
be made even less problematic for "new users/readers" (I'll chose "~"
now for the sake of example):

uses
   myspace~sysutils;

begin
   Exception; // no error
   SysUtils.Exception; // identifier not found
   MySpace~SysUtils.Exception; // no error
end.

With RTL's sysutils:

uses
   sysutils, myspace~sysutils;

begin
   Exception; // normal resolution of duplicated types, so sysutils wins
(or does the last one win? - I can't remember now...) => no error
   SysUtils.Exception // the RTL's Exception
   MySpace~SysUtils.Exception; // Exception from MySpace~SysUtils
end.

Hmm... "~" looks ugly :P

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

Re: Re: Ideas for namespace implementation

Marcos Douglas B. Santos
On Mon, Jul 26, 2010 at 11:20 AM, Sven Barth
<[hidden email]> wrote:

> Hi!
>
> On 26.07.2010 16:06, Martin wrote:
>>>>
>>>> But worst of all
>>>> uses sysutils; // the one from my project?
>>>
>>> No, because the RTL is not compiled with a namespace, so falls under the
>>> "global" namespace with takes preference over project units or all other
>>> namespaces. This then stays consistent with how developers understood the
>>> code as it currently works. Compiler included units take preference.
>>
>> You missed the important bit of this section.
>>
>> let's correct the uses:
>>
>> uses myspace.sysutils;
>> // and only this sysutils, not using the global rtl.sysutils at all
>> ....
>> begin
>> SysUtils.Exception;
>>
>> Now if any one else is to read/review/... the code => they will not be
>> aware of sysutils not being rtl.
>> They will assume that "SysUtils.Exception" is "RTL.SysUtils.Exception",
>> but it really is "myspace.SysUtils.Exception"
>>
>> For me,. that is code obfuscation. In order to keep it human
>> understandable, the unt name "sysutils" (unqualified) must only be
>> allowed to refer to exactly one unit => the one from the rtl, no other
>> one ever.
>>
>> But if we allow the unqualified to only refer to the original rtl one =>
>> then all other SysUtils must be fully qualified at any occurence they
>> have (even if they are the only SysUtils used in that unit).
>> And if the always need full qualification, then they do not differ from
>> a prefix (the dot becomes part of the unti name).
>
> What about that the compiler enforces that you use the fully qualified name
> if you used it in the uses?
>
> e.g.
>
> uses
>  myspace.sysutils; // this sysutils contains an identifier "Exception"
>
> begin
>  Exception; // no error
>  SysUtils.Exception; // identifier not found
>  MySpace.SysUtils.Exception; // no error
> end.
>
> So the declaration of "myspace.sysutils" declares a new pseude-identifier.
> By using a different separator or prefix this could be made even less
> problematic for "new users/readers" (I'll chose "~" now for the sake of
> example):
>
> uses
>  myspace~sysutils;
>
> begin
>  Exception; // no error
>  SysUtils.Exception; // identifier not found
>  MySpace~SysUtils.Exception; // no error
> end.
>
> With RTL's sysutils:
>
> uses
>  sysutils, myspace~sysutils;
>
> begin
>  Exception; // normal resolution of duplicated types, so sysutils wins (or
> does the last one win? - I can't remember now...) => no error
>  SysUtils.Exception // the RTL's Exception
>  MySpace~SysUtils.Exception; // Exception from MySpace~SysUtils
> end.
>
> Hmm... "~" looks ugly :P

IMHO, is better to use the ':' like  myspace:sysutils

uses
  myspace:sysutils;

begin
  Exception; // no error
  SysUtils.Exception; // identifier not found
  MySpace:SysUtils.Exception; // no error
end.


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

Re: Re: Ideas for namespace implementation

Reimar Grabowski
On Mon, 26 Jul 2010 11:23:31 -0300
Marcos Douglas <[hidden email]> wrote:

> IMHO, is better to use the ':' like  myspace:sysutils

Even better C++ style:
 
uses
  myspace::sysutils;
 
begin
  Exception; // no error
  SysUtils.Exception; // identifier not found
  MySpace::SysUtils.Exception; // no error
end.

R.
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
123