On Mon, 12 Dec 2005, Hans-Christoph Steiner wrote:
I agree that this should be avoided. For example, in Java, which I am using as my namespace example, when they made javax.swing to replace java.awt, the objects that did the same thing were named differently (java.awt.MenuItem --> javax.swing.JMenuItem) even though both could have been called MenuItem and it would have worked. Its clearer to have the objects with different yet related names.
What happened there? is it that typically people need to import both java.awt and javax.swing in order to do anything with SWING ? In that case it's almost as if they were in the same namespace. However, I figure writing "javax.swing.MenuItem" is as clear to Java programmers, and I can't imagine them trying to come up with shorter identifiers.
What's the psychology behind "J"-prefixing in Java? Really?
Yeah but this is another thing. Most "libraries" in Pd world are not functional entities. They just happen to be written by the same author.
Even libraries that are assumed to have some kind of functional unity normally don't. A lot of C libraries reinvent OOP, dynamic typing, etc.; in Java those features are built-in, but that just moves the phenomenon at another level, though usually to a lesser extent.
Then if you have a library, and you want want to use its method of sending and receiving, the object name would be obvious. But this would have the disadvantage of becoming unclear when someone does this: [import net] | [receive foo] [send foo] |
Without [import net] those would refer to the usual [send] and [receive] that we also know as [s] and [r]. Questions:
1. What would be the way to use a toplevel name like "send", overriding an import directive? [/send] (leading slash) ?
2. Would it be a good idea to have aliases propagate across namespaces, such that [s] in this case would refer to [netsend] ? And then would it be feasible?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada