Re: Perl 6 design wiki?
Ruud H.G. van Tol schreef: > [Perl6-modules meta-structure] > I am currently building a photo classification system. Each photo is > more or less unique, it has a unique identification code, and a short > and a long description. Both descriptions may even be left empty. The > classification is with keywords (or rather phrases, like 'marble > hall'). A search on '+"marble hall" modern' (or: '+marble.hall > modern') returns all 'marble hall' photos, with the 'modern' ones on > top. The list of key-phrases is extensible and supposed to remain > limited, but of course a user can let it grow out of hand as well. Oops, I forgot one very important relation: the parent. Photos that belong together, are in the same directory. And a parent can have a parent, so there is still a tree that can be traversed. With modules, the 'See also' links can cover that. -- Grtz, Ruud
Re: Perl 6 design wiki?
Mark Overmeer schreef: > Ruud H.G. van Tol: >> [aliases next to hierarchical names] >> @alias::HTTPD::Session -> Apache::Session >> HTTPD::Session -> Apache::Session > > Well, that's a technical solutions... your fill the name-space even > more: I can see no harm in that. > the larger the harder to grasp. I normally use search as the first step. Only then I look around for similar names. So aliases would bring more home for me. > In general, it has many > benefit to pick one name, and solve everything else via a searching > mechanism like search.cpan.org. I agree with that. I am currently building a photo classification system. Each photo is more or less unique, it has a unique identification code, and a short and a long description. Both descriptions may even be left empty. The classification is with keywords (or rather phrases, like 'marble hall'). A search on '+"marble hall" modern' (or: '+marble.hall modern') returns all 'marble hall' photos, with the 'modern' ones on top. The list of key-phrases is extensible and supposed to remain limited, but of course a user can let it grow out of hand as well. -- Grtz, Ruud
Re: Perl 6 design wiki?
* Stevan Little ([EMAIL PROTECTED]) [060305 16:53]: > > to the two new perl books "Perl DBI-(Any)-cpan:TIMB" > > and "Perl DBI-(Any)-mailto:[EMAIL PROTECTED]" > Well, to start with, there is no > C6PAN/SixPan/Whatever-it-will-be-called yet, so there is nothing to > pre-register for. On the German Perl Workshop last week, I stirred things up a little with a BoF session about the subject. Amongst others, Andreas and Juerd where present. > Second, Perl 6 is still (at the very least) a year away from a > (mostly) complete implementation, > So pre-registration for namespaces in an unfinished language > is a litte premature IMO. So, in your opinion, it is easy to extend CPAN to contain perl6/parrot/ etc? Depends on the targets you set. Perl is especially known for its extended library: it is the main reason we still exist. To make Perl6 a success, we have to take care of the library! Just like new languages (like ruby) and ~features challenged Larry to redesign our favorit language, should CPAN be evaluated against new developments. Can we learn from SVN/SVK? Linux/GIT? Packaging like rpm's, etc? The library world grew much more complex with languages, character-sets, webdav, and super-fast networks at home. We do not only need to host Perl6, but also perl5, pir, pasm, partcl, etc etc languages. Quite a large number of people I spoke last week saw the need for major changes in the general set-up of CPAN. But certainly the current one is there to stay as well: CPAN is great. Maybe we can make it greater. Say Perl6 is still 2 years away, than we need to hurry with new plans for CPAN: when the currently eagerly waiting hurd of Perl programmers jump in, it is too late... > And lastly, I really don't like the idea anyway. It reminds me of the > domain-name squatters of the mid-90s. No, what I suggest is just like how cpan works now. But with a little planning ahead. > Some things may just need to stay the same, namespace intact. Anything > else would IMO further the Perl 5/6 gap that will inevitably exist > because of the depths of the language changes. For me, it feels as a big mistake when our new archiving needs are seen as a simple extra glue to the existing CPAN. If we need something smarter over two years, we have to start designing it NOW, and building it tomorrow! Before this becomes a real discussion about the future of CPAN: this thread started with Yuval asking about having a Perl Wiki. It would be nice to have a place where the community can be build, where the wide variety of projects can be organized which are required for a good and large new library. Were we can store presentations and teaching materials for the new languages, and so on. -- Regards, MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Perl 6 design wiki?
* Ruud H.G. van Tol ([EMAIL PROTECTED]) [060305 18:11]: > Juerd schreef: > > hierarchical names make less > > and less sense by the day > > I don't oversee the field yet, but maybe: > Introduce aliases (or hardlinks, in file-system-speak). > Likely in a separate top branch, such as "@alias::". > The @alias-prefix is only necessary when there is a collision. Once upon a time, I had to categorize the subjects of 20k websites in some logical structure, and then I discovered why the yellow pages have a flat organization... Of course, hierarchical names get less and less useful when your set grows larger. But it is better than nothing. > @alias::HTTPD::Session -> Apache::Session > HTTPD::Session -> Apache::Session Well, that's a technical solutions... your fill the name-space even more: the larger the harder to grasp. In general, it has many benefit to pick one name, and solve everything else via a searching mechanism like search.cpan.org. -- MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Perl 6 design wiki?
Juerd schreef: > hierarchical names make less > and less sense by the day I don't oversee the field yet, but maybe: Introduce aliases (or hardlinks, in file-system-speak). Likely in a separate top branch, such as "@alias::". The @alias-prefix is only necessary when there is a collision. @alias::HTTPD::Session -> Apache::Session HTTPD::Session -> Apache::Session -- Greetings, Ruud
Re: Perl 6 design wiki?
On 3/5/06, Mark Overmeer <[EMAIL PROTECTED]> wrote: > * Stevan Little ([EMAIL PROTECTED]) [060305 02:49]: > > On 3/4/06, Mark Overmeer <[EMAIL PROTECTED]> wrote: > > > Could we try to kind-of pre-register name-spaces for perl6 modules? > > > There is no need to do such a thing, we have the 3 level naming scheme > > in Perl 6 now. > > Foo-0.0.1-cpan:JRANDOM > > I know about the naming scheme, but I am not really looking forward > to the two new perl books "Perl DBI-(Any)-cpan:TIMB" > and "Perl DBI-(Any)-mailto:[EMAIL PROTECTED]" > > That you have the possibility to work your way out in namespace clashes > shouldn't directly mean that you let them happen easily. I would really > like to maintain a certain hierarchical name-space structure on CPAN, where > we strive for unique names, although can work around accidental collissions. I agree completely, and to be honest, I think the three level namespace will be more useful in the context of a single company and/or application, and be used more for versioning that anything else. > An other reason to have a kind of module/namespace pre-registration is to > see who is (planning to go) working on what. I think that's needed on the > moment. Well, to start with, there is no C6PAN/SixPan/Whatever-it-will-be-called yet, so there is nothing to pre-register for. Second, Perl 6 is still (at the very least) a year away from a (mostly) complete implementation, and that most likely will not be the "official" one, and only a reference implementation that very few people (read: audrey) will actually use in production. The official version with Parrot and Ponie and few enough bugs to call 6.0.0 is maybe a few years out from that. So pre-registration for namespaces in an unfinished language is a litte premature IMO. And lastly, I really don't like the idea anyway. It reminds me of the domain-name squatters of the mid-90s. Just because I (with my best intentions intact) decide that I want to write World::Domination::Simple in 2006, does not mean that someone else in 2008+ should have to come up with another name because I registered for the namespace I never used (and am unwilling to give up). In addition, while I agree with you that there is some Perl 4/5 cruft in CPAN that really should be tossed, this ignores the legacy apps that might still need to use this code. And as for stealing the good namespaces for writing new (and surely better) but very different Perl 6 modules, I am not actually sure I like that. Of course if the dream of Parrot/Ponie really works 100%, then it will probably be a non-issue, but if it doesn't (and there is yet to be a clear plan layed out as to how we will bridge Perl 5 -> 6), then updating legacy modules to Perl 6 might be something which really needs to happen if people are going to be able to port their larger Perl 5 code within a reasonable amount of time and effort. This is especailly true for modules like File::Spec or Test::More, which so many other modules just use as if they are part of the language. I don't mind re-working my core module to use the new whiz-bang OO features, but I would prefer to be able to automatically (and mechanically) convert my test suite rather than have to covert to some type off xUnit style tests or something. Some things may just need to stay the same, namespace intact. Anything else would IMO further the Perl 5/6 gap that will inevitably exist because of the depths of the language changes. - Stevan
Re: Perl 6 design wiki?
Mark Overmeer skribis 2006-03-05 10:44 (+0100): > I know about the naming scheme, but I am not really looking forward > to the two new perl books "Perl DBI-(Any)-cpan:TIMB" > and "Perl DBI-(Any)-mailto:[EMAIL PROTECTED]" I think that's a very good argument for managing namespace centrally (but not necessarily against using this scheme). > I would really like to maintain a certain hierarchical name-space > structure on CPAN, where we strive for unique names, although can work > around accidental collissions. In principle I agree, but to be honest, hierarchical names make less and less sense by the day, as techniques are combined, and new many new things overlap much. Often it is hard to choose between top level namespaces, or to choose which part of your module name you put first. And once you settle on a name, it's even quite likely that although it describes the way you intended the module to be used, it doesn't cover all the bases. See DBIx::XHTML_Table and Apache::Session, that have nothing to do with DBI and Apache, respectively. More and more, I like cute names that don't really describe the module. We have abstracts for the latter. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl 6 design wiki?
* Stevan Little ([EMAIL PROTECTED]) [060305 02:49]: > On 3/4/06, Mark Overmeer <[EMAIL PROTECTED]> wrote: > > Could we try to kind-of pre-register name-spaces for perl6 modules? > There is no need to do such a thing, we have the 3 level naming scheme > in Perl 6 now. > Foo-0.0.1-cpan:JRANDOM I know about the naming scheme, but I am not really looking forward to the two new perl books "Perl DBI-(Any)-cpan:TIMB" and "Perl DBI-(Any)-mailto:[EMAIL PROTECTED]" That you have the possibility to work your way out in namespace clashes shouldn't directly mean that you let them happen easily. I would really like to maintain a certain hierarchical name-space structure on CPAN, where we strive for unique names, although can work around accidental collissions. An other reason to have a kind of module/namespace pre-registration is to see who is (planning to go) working on what. I think that's needed on the moment. -- MarkOv Mark Overmeer MScMARKOV Solutions [EMAIL PROTECTED] [EMAIL PROTECTED] http://Mark.Overmeer.net http://solutions.overmeer.net
