Hi Andreas, Quite a while ago we had a discussion concerning namespace issues with my URI::Bookmarks suite of Perl modules (last e-mail in the discussion is quoted below). I'm currently extending the suite to provide support for Mozilla, Lynx and Internet Explorer, so I'd really like to get these namespace issues cleared up as soon as possible. If you still aren't happy with my naming decisions (despite my best efforts to convince you in the text below ;-) then let me know what I can do to resolve the problem and I'll get to work on it straight away. If on the other hand I've managed to persuade you, could the suite can be registered on the module list please? Cheers, Adam Adam Spiers ([EMAIL PROTECTED]) wrote: > Andreas J. Koenig ([EMAIL PROTECTED]) wrote: > > Maybe it's just me, but I find it fundamentally confusing to have two > > namespaces xxxBookmark AND xxxBookmarks. > > I know, it's not great, but I put a lot of thought into this and still > decided that it was best (in fact, necessary) to separate the two > concepts: > > 1) a collection of bookmarks > 2) a single entry in the collection > > Once you are aware of this separation, I think everything should become > very intuitive. > > The reasoning for the necessity is as follows: > > I really wanted to use the excellent Tree::DAG_Node module. You only > have to read the documentation for this module to see that it's extremely > powerful and worthwhile. This meant that a single entry in a bookmark > collection (be it bookmark, bookmark folder or anything else) should > belong to a subclass derived from Tree::DAG_Node. This in turn meant > that a whole collection of bookmarks would be represented by the root > node of the bookmark tree. However, the collection as a whole needed to > be able to have other information associated with it, e.g. where the > collection originally came from (such as a Netscape bookmarks file, in > foo/bar/.netscape/bookmarks.html). Now, this other information should > not be stored as attributes inside the root node of the bookmark tree, > since one of the operations you should be able to do on a collection of > bookmarks is change the root of the tree, and in this case that would > mean having to move these attributes from the old root node to the new > root node, which is ugly. > > As it is currently, I think that the overall design is (IMHO ;-) quite > elegant. The main problem is the namespace issue. As is hopefully > already clear, URI::Bookmarks and URI::Bookmarks::* relate to concept 1) > above, i.e. a collection of bookmarks, whereas URI::Bookmark and > URI::Bookmarks::* relate to single entries in the collection. If you > have better suggestions for a better choice of naming I'll gladly accept > them. May you'd rather that I changed them as follows? (Using the > seemingly unwritten convention that lowercase module names such as > URI::file::* are sometimes private.) > > old -> new > URI::Bookmarks URI::Bookmarks > URI::Bookmarks::XXX URI::Bookmarks::XXX > URI::Bookmark URI::Bookmarks::bookmark > URI::Bookmark::XXX URI::Bookmarks::bookmark::XXX > > Eww, that's probably even uglier :-) At least it would keep > URI::Bookmarks* cleanly separate from other modules. Like I said, > suggestions welcome... If you think the namespace problem could be > solved by a complete redesign of the OO structure then I'd be equally > interested in hearing how, since I spent a fair bit of time thinking > about it and couldn't come up with anything else which satisfied me. > > Adam -- --- [EMAIL PROTECTED] --- musician and hacker --- http://www.new.ox.ac.uk/~adam/ echo '$_=bless[q]]],q;_;;sub s;{local$_=shift;push@$_,++$0,pop(@$_).$s;;$_}($, =eval((join"\$_->[",qw)Just Another Perl Hacker)).q)$_->[1]]]])))=~s~((?<=.(?{ ++$*})))?_::~$*&&$"~egx,print""=>""=>'|perl -ln0e';s;s\;;_::AUTOLOAD$1;g;eval'
