Hi Francesco,
> Il 12/02/2009 19.17, Viktor Szakáts ha scritto: > >> We can even have these in parallel, and if we go this route, we should >> gather all these <dialect>_*() dialect prefixed functions in separate files >> (for clarity and future development), and user can easily map the one they >> need using "FUNC TTOS( x ) ; RETURN *_TTOS( x )" [ or with null overhead in >> C ], or even use them in parallel. Later we can move these dialect dependent >> implementations into separate libs, which would allow to use the original >> names, of course in this case collision may occur if someone links multiple >> one with such colliding names, but I don't this is a problem in practice. >> >> This will open an interesting discussion on a possible namespace > implementation, like Ron did in xharbour (but I never tried it and I don't > know any implementation detail), that I think will be useful in some cases. > Obviously this is a future request possibly for harbour 2.0 ;-) > But I begin to thought to this thinking if it possible to create a *small* > php wrapper to use in uHTTPD server (only an idea, I don't think to any > implementation detail) where I can take a php source and paste it in a hrb > module, but using activating a namespace functionality to redirect any > function to a PHP_*() internal functions and have no collision with > harbour/clipper namespace. Yes, interesting idea to remap a whole set of functions to another namespace. This might help on the "sandboxing" problem when running non-trusted scripts in an app environment. If we define a namespace with all allowed functions and apply that namespace to the macro compiler, this may solve the problem, as not allowed one will simply err. It's also useful for 3rd party lib developers (including contribs). I don't know the xhb implementation either, so it's difficult to comment, the devil is in the details probably. Overall I feel this should come a bit later, and even before that it'd be great to separate dialect specific functions and classes into libs, so we get the ability to choose features at runtime, rather than build time. Later with namespace this can be made even more flexible, but it's not a requirement. We could even go as far to move these dialect libs to contrib, which allows more freedom for developers. In fact we already have one such lib: xhb.lib. If this becomes a system, we may use some common prefix for these libs (hd = Harbour Dialect): hdxpp, hbfs, hdx, hdfox, hdvo, hbclip. These could replace current HB_COMPAT_* macros, but with much more possibilities. [ Since we're pretty much compatible with C5.3 without any big drawbacks, and the implementation is finished, there is no need to move it a separate dialect lib. ] And BTW, it's not just dialects, but even things like WAPI_, if we make it right now, it will be later much easier to just switch to namespaces, as we already have an analogous system. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
