On Wed, Nov 13, 2013 at 7:11 PM, Sieghard <[email protected]> wrote: > Hallo Marcos, > >> > ISO extended Pascal has a feature allowing the re-export of aliased >> > symbols from arbitrary compilation units (they're not named "unit" > ... >> If I understood right, we can do the same using FPC. You can "rename" >> a class or function (using a variable that use the same signature) but > > AFAIK not so - or at least not to pass on the "renamed" item. I'm not even > sure that you can do this within one unit, you might still have to provide > an "implementation", even if that's just a call with the identical paramter > list that the compiler _might_ optimize away (if it recognizes it). > >> the problem continues if we have two -- or more -- units with the same >> name. > > Yes, that's hardly anywhere addressed, and it's not addressed by the ISO > standard I mentioned. There, you can rename any name imported from any > external module ("unit"), but you cannot in a standardized way select the > external module imported from, should there be multiple possibilities. > Of course, that was done to avoid any restrictions as to how the modules > might be addressed by the hosting environment, but this constitutes a > restriction by itself. > >> The compiler should provide a way to assign a directory to a >> 'Namespace' named by programmer, eg: Synapse. > > Why a "directory"? Why not a specific file? Or, why not allow for > specifying imported units - additionally - by a complete path?
I said "directory" because is simpler to understand but can be a package, lib, framework, directory, file, etc. I guess using paths in sources is not a good idea. You will use "/" or "\"? IMHO, only the compiler need to know paths. > Of course, this selects a specific running environment for the project, but > if the specification allows for sufficient variablity (any characters > allowed in file specification, e.g.), it might be suffiently universal. I keep thinking: paths, only for the compiler. >> This lib has units like httpsend, ftpsend, etc. >> If you have, in your own project, these unit names, you could use a >> Namespace for Synapse like this: >> fpc /src/synapse/* -alias synapse >> (of course I invented this sintaxe right now) > (syntax) > You might otherwise be able to specify > > USES > Synapse in "/home/marcos/MSElang/Synapse.pp", ... > (or > Synapse in "./Synapse/Version_2.3/Synapse.pp", ... > i.e. relative paths, even.) > > following a similar attempt by Lazarus. No new syntax element needed, just > an extension of analready present one. I proposed do the same but using this sintaxe only for compiler. The code should stay clean. Using a "alias", you can point them to another implementations just changing the compiler script. If you put paths inside sources you will loose this. >> In your projects you could use Synapse's units like: >> uses >> synapse.httpsend, synapse.ftpsend, >> httpsend; // this is your own unit! > > Ok, you would have to be more specific and have to write a bit more (mostly > "copy&paste") with my suggestion, but could effectively do the same. My idea is to use a "item" using a "virtual name" instead of the real name. Just it. Do this in a directory is more productive than for each unit. But we can have both. Regards, 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
