We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProcessing DevelopmentLibraries,  Tool Development › A dedicated suffix for Processing libraries
Page Index Toggle Pages: 1
A dedicated suffix for Processing libraries? (Read 909 times)
A dedicated suffix for Processing libraries?
Apr 23rd, 2009, 5:24am
 
Hello everyone,

after launching the PTurtle library, Andreas and I have been discussing library names and considering the merits of there being a dedicated Processing suffix (perhaps P, P5 or Pro) available for Processing libraries.

You can read our full posts in the PTurtle thread, also in the libraries and tool development forum. Here are the relevant parts of our our conversation so far:

Quote:
Andreas "i am just worried, that the naming does conflict with the convention of using prefix P only for "official" things that are inside processing.core and other associated classes. but chaning the name of pturtle would then also affect your current sourceforge url. any suggestions?"


Quote:
Ollie "We came across the library naming rules after registering the SourceForge project and decided to use PTurtle for the time being while we got our first release out.

We're aware it's problematic; we'd like to indicate that our library is for use with Processing, but all of the desirable suffixes, P, P5 and Pro, are reserved. Indeed, without modification, the library won't work with anything else, making JTurtle or something more generic undesirable. I imagine that a number of developers have had this difficulty and I can see there are several Pro- and P5- libraries on the library page.

Could I suggest a long term, mutually beneficial solution? How about dedicating one of the "p" suffixes to third party library developers, say P5? With such a nomination, we could all enjoy library names that reference Processing without encroaching on the official, core API namespace.

How does this sound to you?"


Quote:
Andreas "ironically 2 of my libraries do fall under the suffix-issue as well. for libraries i am working on now, i decided to use an 's' as prefix - giving up the P5 suffix. doing so, my future libs might be less connected to processing in its naming convention but more connected towards the author.  i do see that it might be useful to have a dedicated prefix or suffix that makes it easier to identify processing libraries, yet i dont know if it should be a requirement - but an option. what do others think? (maybe this should continue in its own thread?)"


What do other developers think? Do you agree that a suffix would be useful? What would you prefer it to be, and why?

Best wishes,

Ollie
Re: A dedicated suffix for Processing libraries?
Reply #1 - Apr 24th, 2009, 6:58am
 
Actually, I see suffixes (or, rather, prefixes!) as a thing of the past, back to an era (C, perhaps early C++) where namespaces didn't exist.
They helped a bit in avoiding (most) name clashes.
In Java, packages are supposed to remove the need for suffixes, they are, somehow, super-suffixes!

Now, if I look at our own sources at my work, I see we have in the 'workspace' package classes names WorkspaceContainer or WorkspaceSubDocument...
Seems a bit clumsy, but at least it is clear, and if you ever need to use both WorkspaceContainer and, say, ProjectContainer, there is less risk of clashes or need to provide fully qualified names...

Issue might happen with external libraries targeting same system. Having several concurrent Rectangle or Shape classes might be troublesome (I believe such issue happened with XML libraries).
Now, having a common prefix for all Processing libraries will solve nothing...
Maybe it is up to each contributor to find out their own original/unique names, avoiding at least to clash with Processing's official prefix (P).
Page Index Toggle Pages: 1