> Importing symbol from another namespace can be done with > > (intern 'myNames~Foo) > -> Foo > > This will make the symbol 'Foo' from 'myNames' available as an internal > symbol in the current namespace. >
This is imo a must have feature, it has to be up to the programmer to avoid "clashes" as it is his problem to avoid similar pitfalls in all interpreted languages. Contrast with Clojure for instance, the below will not compile so the compiler protects you from yourself: (require foo.bar.blabla.abra.kadabra.func as func) (defn func) Having to write the full name all the time could easily become comical, as in my above Clojure example. This is also one of the reasons I have leaned towards OO encapsulation since I then can subclass everything. (func> '+Kadabra arg1 arg2) is shorter than: (foo.bar.blabla.abra.kadabra.func arg1 arg2) On Mon, Sep 19, 2011 at 2:04 PM, Alexander Burger <a...@software-lab.de>wrote: > Hi Thorsten, > > > one question with regards to this topic: > > what would be the advantage of namespaces in Picolisp over > > namingconventions like in Emacs Lisp? > > Right. Not much. > > > 'gnus-function-name' for all functions in gnus library > > 'dired-function-name' for all functions in dired library etc > > Yes. Such conventions make things transparent. The drawback might just > be readability of the longish symbol names. > > I suggested something like this in my reply to Henrik (on Sep 5th, using > the 'dot' as a delimiter): > > > A call like > > > > (foo> '+Pckg <arg>) > > > > is in no regard more encapsulating the namespace then > > > > (foo.Pckg <arg>) > > Cheers, > - Alex > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
