On Sun, Sep 13, 2009 at 11:31 PM, Marvin Humphrey <[email protected]> wrote: > On Sun, Sep 13, 2009 at 06:59:01PM -0700, Nathan Kurz wrote: > >> do you allow for Lucy::Dir1::Class and Lucy::Dir2::Class, or does 'Class' >> have to be unique across all groupings? > > 'Class' has to be unique across all groupings.
OK. I knew that was the case in the past, but I thought I'd seen something flash across indicating that had changed. This seems like a design decision that is going to bite back someday. > At least within the confines of Lucy. Theoretically you could create another > Boilerplater "parcel" -- e.g. "Lucy2", or "KinoSearch", or "LucyX" -- which > also had a "Class". That's not well developed in Boilerplater because it > hasn't been been necessary yet, but it's doable. You mentioned in an earlier message that it might be good to view Lucy::Search as LucySearch. Maybe it should be spelled this way as well, so that instead of the symbol for Lucy::Search::Class::func being named lucy_Class_func(), name it lucySearch_Class_func()? I wouldn't be against lucy_Search_Class_func() either. I think either way would be the same as defining a separate Parcel for Lucy::Search, and making the Group the same as a Parcel. The standard macros would still allow the internal use of Class_func(), but anything cross-Group would have to use full names. Or I suppose you could include macros from both Parcels and fail on redefinitions. You've thought about this much more than I have, but I think a clearly defined 1:1 mapping between C symbol and Perl/Python class is going to make things easier. When I said earlier that it would make things easier to always using the second level namespace to represent grouping, this was because I though the Group name already was part of the symbol name --- Lucy::Search::Class::func -> lucy_Search_Class_func() --- and that having a consistent format would allow for easier translation. This seems straightforward enough that I fear I must be mixed up, or missing some essential piece of information. Nathan Kurz [email protected]
