Krzysztof Czaja wrote:
hi all,
why on earth do we need two separate implementations of the abs~ class? They seem equivalent. And, after all, the abs~ is to be included in the Pd proper at some point...
Of course, we do not need to separate implementations of the [abs~] class ! In fact, in this special case, they are not 2 separate implementations, but 2 100%-compatible classes packed into 2 separate libraries (!). Why ? For pure convenience, because when distributing pd-work on small floppy-disks, the big Gem-project (even if we talk about the binary-only distribution) just will not fit on the media !
So what should we do then ? Of course, I could split Gem up again into Gem+markEx, but then there arises the problem that most of markEx is really useful for work with Gem. The not-so-useful-for-Gem-objects are maybe [abs~] and [reson~]. Should i split the package then ?
my personal opinion (and yours too, i see) is, that it would be best to include [abs~] in the main pd release.
All the talk i have made up till now used the [abs~] only as an example. Worse problems occur with not-so-obvious classes like [scale]
Well, having namespaces in Pd would be a dream come true for some users (including myself), but from the pov of many more users it would have been much better, if the coders agreed to avoid name duplication at all costs, either merging their efforts, or using pre- or postfixes or whatever.
I think, even if there are namespaces, people mostly tend to ignore them, unless they are forced to comply.
Well, my idea is to make namespaces handled by the library loader of pd. This is, the namespace is not handled by the programmer. She just writes a library (pe "zexy") and with classes like "matrix~". When the pd-library-loader loads "zexy", it inserts the new classes not as "matrix~" but as "zexy::matrix~" (please ignore the ascii-value of the delimiter) and furthermore tries to add a class_creator "matrix~", which is allowed to fail, because someone has ignorantly written a library "matrixlib" that provides the "matrix~"-class and has been loaded before.
so i would encourage programmers of libraries to not use (artificial) namespaces for their classes until...
mfg.fsd.sdr IOhannes
Krzysztof