On Thu, Nov 14, 2013 at 9:52 PM, Sieghard <[email protected]> wrote: > Hallo Marcos, > > Du schriebst am Wed, 13 Nov 2013 22:26:19 -0200: > >> >> 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 > > Well, I don't think this was simpler to understand - not for me, anyway. > >> 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. > > That's certainly true, a it "bonds" the source file to a certain system > environment. But on the other hand, you _have_ to provide some means to > access necessary external resources - so this is somewaht a dilemma. > BTW, it's not so much an issue whether to use "\" or "/", after all, the > prime system using "\" also understands "/" as a path element separator, > but what about systems using something else? I think to have seen some > system using ":" for that purpose, other characters might be in use as well.
Java uses "." ;-) >> I keep thinking: paths, only for the compiler. > > Then you have to devise a method to specify them, and possibly store them, > for use on a specific system. You should _also_ keep in mind that it might > be of use, even necessary, to migrate projects between systems, ans then > between systems which have different path setups. It shouldn't be too > complicated to readjust the setup in this case, certainly not so horribly > distributed over many places as is common with Windows (the registry, > configuration files, associations, and more). We will use in the same way we use now, ie, using as compiler parameters. >> I proposed do the same but using this sintaxe only for compiler. The >> code should stay clean. > > I.e. you want to use something like compiler macros. > >> 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. > > Not really - you _have_ to have a way for storing these definitions. > Whether in a source file or elsewhere, you will have to adjust them on > another system. But a separate file - if properly documented - may have the > advantage of keeping these definitions in a single place. Per project, at > least. I don't understand where you see the difference... The (new) ALIAS parameter is only one more parameter to compiler... that's all. >> My idea is to use a "item" using a "virtual name" instead of the real >> name. Just it. > > I.e., use compiler macros. I do not know how Martin will implement this. I guess he will chose the simple way... if is compiler macros, Ok for me. 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
