On Wed, 27 Sep 2006, Frank Barknecht wrote:
But, yes: This would be worse, if you wouldn't even know, which [+ ] object is used, depending on which namespace is active.
The decoupling of the name and the thing that the name refers to, is called late binding.
Wouldn't it be bad if you wouldn't even know, by sending a message, what are the classes of the objects that will receive that message! Well, that's what Pd/Max has always been, it's one kind of late binding, and it's the basis of polymorphism, which is a feature (or a set of features) that are very much sought for, because they increase context-dependency, which makes the code shorter *and* allows you to configure the code by changing its context.
If you liken pd messages to function calls, their context is the objects that the messages are sent to; it's context-sensitive: the receiver _is_ the context (or from another point of view, the class of the receiver _is_ the context).
in the case of making a [+] object, the receiver is ;objectmaker because pd unifies class lookup and method lookup. Now why would it be a bad idea to make ;objectmaker replaceable by something else? It's not so clear to me, given how pd is already made.
However I don't want to be forced to write patches like: [pdcore/float]
If namespaces force you to write complete names all of the time, then there is no difference between that and just considering slashes as part of the name and not thinking about namespaces.
In that sense, Perl5's namespaces are bullshit, just more syntactic noise; while namespaces are actually implemented in Tcl, Python, Ruby, C++, Java, ...
(Perl5 really implements its "namespaces" hierarchically, but you can't feel it until you ask a namespace to list its contents... there are no other benefits to namespaces in Perl, that I know of)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada