[PD-dev] removing files from externals/build/src

[Mathieu Bouchard]

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