On Sun, Nov 17, 2013 at 5:41 PM, Sieghard <[email protected]> wrote:
> Hallo Marcos,
>
> Du schriebst am Sat, 16 Nov 2013 21:20:28 -0200:
>
>> > Java? I don't know of either an operating system named "Java" or a file
>> > system of that name, only a programming language called so. Programming
> ...
>> I was talking about Java language, of course.
>> Pascal uses units. Java uses packages. Packages are referenced by your
>> paths but you do not uses "\" or "/" but uses "."
>
> Ok, then either I didn't understand what you were out for or your point
> wasn't stated clearly. You wrote
> "The compiler should provide a way to assign a directory to a
> 'Namespace' named by programmer, eg: Synapse.
> "
> and that one should be able to assign a
> "Namespace for Synapse like this:
> fpc /src/synapse/* -alias synapse
> "
> which requires the use of a file system path specification.
> That's what I referred to, but perhaps that wasn't what you intended.
Yes, but the paths are used only in command line to compiler -- did
you see the fpc binary call? -> fpc /src/synapse/* -alias synapse
The paths are not in sources... that's I meant.
>> > somehow specify where to find the source files a project uses. Usually,
> ...
>> MSE has .prj file; Lazarus has .lpi file; you can use your own script too.
>> The language should not care about paths... only the compiler. I mean
>> the concept "where are the files" is not a language concern.
>
> That's right, and thus, there's no place to use anything to that end within
> a source file, not even an "alias", as you called it, referring to a
> specific place in the host system. If something to that end is to be used,
> path resolution should be done at a level "above" the source level, e.g. it
> might be done by specifying an exact path for each unit in the project file
> as mentioned above. Neitzher Lazarus nor MSEIDE do it this way now, but it
> could be added, e.g. similar to this:
>
> [units]
> unit1=${projectdir}/level1/file1.pp
> unit2=${projectdir}/level1/file2.pp
> unit3=${projectdir}/level2/file3.pp
> unit4=${projectdir}/level2/level3/file4.pp
> unitx=/somewhere/else/in_the/filesystem/external.pas
> main=${projectdir}/file0.pas
>
> You certainly can guess how this would be used in the project source.
You're correct and that is exactly what I'm trying to explain! :-)
So, the new ALIAS compiler parameter can be persisted in a config file
-- like you wrote above -- but this is only a detail... the most
important is the programmer can tell to compiler that one unit -- or
unit group, package, lib or framework -- is used with other name.
I didn't understand if you can mean this in your example, ie, if I can
use unit1 in sources but the compile will use
${projectdir}/level1/file1.pp
If you mean this, Okay, this is I want. The only difference to my idea
is I write a ALIAS for an unit group (directory) because I do not want
to rename all units in a directory (package). So, following your
example I prefer to use:
@Level1=${projectdir}/level1/* // the "@" is the sintaxe for an ALIAS
Now I can use all units in ${projectdir}/level1/ like this:
uses
Level1.file1, Level1.file2;
More productive, don't you think?
--
Marcos Douglas
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
mseide-msegui-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
