On Mon, 8 May 2006, Hans-Christoph Steiner wrote:
On May 7, 2006, at 6:56 AM, Mathieu Bouchard wrote:
On Thu, 27 Apr 2006, Hans-Christoph Steiner wrote:
I think these should be more descriptive. They don't work exactly the same as the core versions, so they should have different, but similar, names.
Why should namespaces exist if they don't solve name conflicts?
Ok, to follow this logic, we should stop coming up with new names for objects. All libraries will use letters for object names starting at A. core/a core/b
No, this doesn't follow this logic. I'm questioning the use of namespaces and then you pretend that I question the use of names. That's not a very subtle strawman. If you were actually thinking about class_addmethod2, that one used letters for the same reason that [t] accepts letters; but that's not what you're replying to.
those names all contain "osc" twice. if the latter "OSC" can't be removed, then why not removing the leading "osc/" ?
Because if you do this: [import osc] [packOSC]
What if you did the following instead?
[osc/pack]
it seems to me as being just as descriptive and plus it's shorter because you don't have to write [import] and the name of the objectclass itself is hardly longer.
I would need an example that involves several classes called [packOSC] so that I can see an advantage related to nameclashes.
A fundamental idea in programming is to name things descriptively so you can easily read the code. Just because we can reuse the same names, doesn't mean we should. The object name should represent what it does as clearly and compactly as possible.
But is a name including the package name that it's in? In one sense yes and in one sense no. By using the slash as a separator you suggest a filename analogy, and the word "filename" has been traditionally used to mean both the local slashless name and compound names (which include both relative and absolute names).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada