Re: Namespace advice for Git-related package
On 10/27/2016 11:25 AM, Smylers wrote: James E Keenan writes: Alternatively, Devel::Git::MultiBisect would indicate that this is a tool for Perl development use. And that's what I ultimately went with! This is indeed a developer's tool. http://search.cpan.org/dist/Devel-Git-MultiBisect-0.01/ Thank you very much. Jim Keenan
Re: Namespace advice for Git-related package
James E Keenan writes: > I am in the process of developing a CPAN library which I am > considering calling Git-Multisect-Perl. ... > > 'Multisect::' is chosen to contrast with 'bisect'. That hadn't occurred to me. I read it as a contraction of ‘multiple sections’ or similar. > When we speak of bisection in the context of, say, Perl 5 core > development and use of Porting/bisect.pl, we're usually looking for a > single answer to a question, e.g., at which specific commit did this > test file start to experience failures. Recently, however, we have a > case where a file failed in different ways over many months. That's > the actual use case which led me to develop this library. However, ‘bisect’ is a well known word for this activity. Sometimes with naming things it's clearer to be familiar-but-approximate rather than accurate-but-obscure. Once the name has got somebody's attention, the docs can explain nuances. I think Git::MultiBisect or Git::Bisect::Multiple get the idea across more obviously. > The '::Perl' in the namespace is intended to say, "This is a way to > apply the concept of multisection to typical needs in Perl development Unfortunately I don't think it does that. A suffix of ::Perl usually indicates that it's implemented in Perl — either because there's also an ::XS variant, or it's a port of a library that originated in Java or some other language. I'm not sure there is anything which indicates ‘typical for Perl development’. I'd omit that aspect from the name. > we don't want to foreclose the possibility of future libraries which > use git to perform multisection in other problem spaces." Let any hypothetical future rival Git-multi-bisect distribution — and there may not be one — come up with an adjective that distinguishes itself from yours. Alternatively, Devel::Git::MultiBisect would indicate that this is a tool for Perl development use. Good luck! Smylers -- http://twitter.com/Smylers2
Re: Namespace Advice
Hello Chris, Chris Dolan wrote: On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Because not only MS documents can be read? There is also the possibility to read the summary informations from text and and other files, if there is a summary information available. Reinhard
Re: Namespace Advice
Hello Chris, Chris Dolan wrote: On Apr 7, 2005, at 8:28 AM, Reinhard Pagitsch wrote: Hello Chris, Chris Dolan wrote: On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Because not only MS documents can be read? There is also the possibility to read the summary informations from text and and other files, if there is a summary information available. Reinhard Hmm, I think it must be my Mac experience showing through. I'll defer in this case, but permit me to further detail my thoughts anyway... When I think Document I mentally include any non-active file, including MS Office files, text files, PDF files, etc. but excluding executables. To me Win32::Storage and Win32::File suggest the manifestation of the file in the filesystem, not the the contents of that file. The summary information of a Win32 (NT/2000/XP/2003) are not part of the content of the file. MS tells about Structured Storage it the following: [quotation] Structured Storage provides file and data persistence in COM by treating a single file as a structured collection of objects known as storages and streams. The purpose of Structured Storage is to reduce the performance penalties and overhead associated with storing separate objects in a single file. Structured Storage provides a solution by defining how to treat a single file entity as a structured collection of two types of objectsstorages and streamsthrough a standard implementation called Compound Files. This lets the user interact with and manage a compound file as if it were a single file rather than a nested hierarchy of separate objects. And also: Traditional file systems face challenges when they try to store efficiently multiple kinds of objects in one document. COM provides a solution: a file system within a file. COM structured storage defines how to treat a single file entity as a structured collection of two types of objects storages and streams that act like directories and files. This scheme is called /structured storage/. The purpose of structured storage is to reduce the performance penalties and overhead associated with storing separate objects in a flat file. [end quotation] So these informations can be stored for any file, including executables and dll's, as I understand this, or I am wrong? Ok, in these two explanations they only speak about compund files, but as I know you can also use it for executables and dll's. Reinhard
Re: Namespace Advice
On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: Namespace Advice
On Apr 7, 2005, at 8:28 AM, Reinhard Pagitsch wrote: Hello Chris, Chris Dolan wrote: On Apr 6, 2005, at 11:06 AM, Reinhard Pagitsch wrote: I would suggest now to name the module Win32::Storage::ReadSummaryInfo. I like this better than before, but why not Win32::Document::SummaryInfo? Because not only MS documents can be read? There is also the possibility to read the summary informations from text and and other files, if there is a summary information available. Reinhard Hmm, I think it must be my Mac experience showing through. I'll defer in this case, but permit me to further detail my thoughts anyway... When I think Document I mentally include any non-active file, including MS Office files, text files, PDF files, etc. but excluding executables. To me Win32::Storage and Win32::File suggest the manifestation of the file in the filesystem, not the the contents of that file. But perhaps my vocabulary of simply off base. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
Re: Namespace Advice
Hello Chris, Chris Dolan wrote: On Apr 5, 2005, at 2:44 AM, Reinhard Pagitsch wrote: Win32::File::Prop - Perl extension read property informations from MS compound files and normal files, if the properties are set. Question: Is this really Win32 specific? Are you using Windows-only functionality, or would this module work fine on non-Windows computers (like the Excel and OLE modules do)? Yes the module is really Win32 specific because it uses the functions for the Structured Storage, and I do not belive these functions are available on Linux/Unix systems or cygwin. As I made tests also with OpenOffice documents and saw that there the informations stored in a different way so I have to check the OOo SDK to get the informations I need. I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Or maybe Win32::Storage::PropertySet? Reinhard Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/)
Re: Namespace Advice
Le mercredi 06 avril 2005 à 12:11, Smylers écrivait: Reinhard Pagitsch writes: Chris Dolan wrote: I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Or maybe Win32::Storage::PropertySet? I would expect something with storage in its name to be quite low-level; it wouldn't occur to me that it would deal with document-specific properties. Also PropertySet makes it sounds that it _sets_ properties, whereas you said your module reads them. It all depends if you hear set as a noun or as a verb, doesn't it? -- Philippe BooK Bruhat The shortest distance between two points is not always the safest. (Moral from Groo The Wanderer #69 (Epic))
Re: Namespace Advice
Philippe 'BooK' Bruhat writes: Le mercredi 06 avril 2005 à 12:11, Smylers écrivait: Also PropertySet makes it sounds that it _sets_ properties, whereas you said your module reads them. It all depends if you hear set as a noun or as a verb, doesn't it? Yes, but it's quite common for modules to be Noun::Verb, such as Email::Send for instance. My point was that it's ambiguous, and therefore less preferable than a similar name that couldn't cause such confusion. Smylers
Re: Namespace Advice
Hello Smylers, Smylers wrote: Reinhard Pagitsch writes: Chris Dolan wrote: I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Or maybe Win32::Storage::PropertySet? I would expect something with storage in its name to be quite low-level; it wouldn't occur to me that it would deal with document-specific properties. The module gets the informations which would be displayed in the Summary information dialog if you right click on a MS document (Word, Excel, ...) chooseing Properties in the popup menu. But it can also read none MS documents like text files, if there are extra informations stored. (I just tested it with MS documents and normal text files.) Also PropertySet makes it sounds that it _sets_ properties, whereas you said your module reads them. Hmm, you shall read it as a Set of Properties not setting properties. I would suggest now to name the module Win32::Storage::ReadSummaryInfo. Reinhard Smylers
Re: Namespace Advice
On Apr 5, 2005, at 2:44 AM, Reinhard Pagitsch wrote: Win32::File::Prop - Perl extension read property informations from MS compound files and normal files, if the properties are set. Question: Is this really Win32 specific? Are you using Windows-only functionality, or would this module work fine on non-Windows computers (like the Excel and OLE modules do)? I think Document may be better than File in this case. My first impression was that Win32::File::Prop is would interact with Windows filesystem properties, like permissions, hidden flags, ownership, etc. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) PGP.sig Description: This is a digitally signed message part
