[Portland] xdg-utils: common return values [CORRECT PATCH]

Kevin Krammer kevin.krammer at gmx.at
Sun Apr 30 08:47:51 PDT 2006


On Sunday 30 April 2006 17:06, Jeremy White wrote:
> > Hmm. How about build time including the xdg-include file in the scripts,
> > but still have it separated from xdg-utils-common-in?
> >
> > This way we have
> > - each script working stand alone
> > - a file to include for scripts using xdg-utils (xdg-include or
> > xdg-utils-include), quite like a public header file
> > - a file to separate common scripts parts into for easier development
> > (xdg-utils-common.in) quite like a private header file
>
> To be honest, I think my first patch accomplished essentially
> the same thing, but was simpler.
>
> Thus, instead of having xdg-utils-common.in and
> xdg-includes, just have a single xdg-utils-common
> which provides both functions.
>
> The downside is that we may end up with a lot of
> cruft in xdg-utils-common that we might prefer be
> internal use only, and now it's exposed to outside view.
>
> I don't really feel all that strongly about it;
> either way we solve it works for me.

It works for _me_ either way as well, however I am afraid that once we install 
a file with internal utility functions, they will not remain internal and we 
loose the capability to change them if we need to.

The functions would become some kind if shell API and we would have to care 
about namespacing, compatability, etc while now we only use the file as a 
convenient way to avoid copy&paste for common code.

> I do think it would be really great, though, to provide
> a named set of return codes and start being consistent
> about using them by name, just for the the documentation
> value I think it will bring.

I fully agree, it is good practice in other programming projects as well to 
not depend on hard coded values but on named constants.

I don't think anybody objects the idea itself, we are primarily arguing about 
the implementation possibilities.

I'd just like to keep the option to have shared but non-public code.
(non-public in the sense that it can of course be used according to its 
licence but we can e.g. remove it when out script do not need it any longer)

Cheers,
Kevin
-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20060430/89175c8c/attachment.pgp


More information about the Portland mailing list