On Feb 12, 2006, at 12:02 PM, cyrille henry wrote:
hello Ben
B. Bogart a écrit :
cyrille henry wrote:
i don't fear redondancy.
Hi Cyrille, Perhaps you don't but anyone who is learning PD should! Without consitancy and a lack of redundancy learning PD becomes a much more complex and confusing proposition. Wherever possible objects with the same functionality should be unified.
yes. i want to unified mapping objects together. and list objects together.
i think mixing list object with mapping objects for a patch is confusing. mapping object should be consistant, and one should not use list object when he's looking for a mapping object.
I don't think this should be a problem at all and its quite common with many programming languages. In C, libc doesn't have any math functions in it, they are in libm. In Java, java.lang.* does not have any GUI classes at all, you have to use java.awt.* or javax.swing.*.
"mapping" should be a library like java.awt, and "math/list" also.
Otherwise things tend towards a state where the dominant (first written) object gets priority in patches and in workshops. Then the users miss the second object, that might be better, and then we end up with different camps of users using different versions of "functionally" the same object, and incompatible patches. Its my personal opinion that one should never write an object that overlaps more than 60% of the functionality of an already existing object. One should "fix" the existing object to cover the 40% the new object would allow.
ok. so let's embeded a [list_clip 0 1] in the mapping_clip. what do you think?
[mapping/clip] object would just be a shortcut, which could also create confusion. If someone imports "math/list" before "mapping", then [clip] would loose its defaults. So I think that it would probably be a better idea to just use [math/list/clip] in the context of mapping. If we start making distinct math objects for the mapping lib, where will it stop? Should we have [mapping/*], [mapping/cos], etc. etc. also?
If you really want to write your own redundant objects then please don't bother releasing them. It just adds to the chaotic fuzz and it would serve the community much better to integrate rather than "fork" even if its hard and takes longer.
i don't think it's chaotic to have all object need for mapping in a mapping folder, and all object need for list processing in a list folder...
This structure worked well when you had to work around Pd's lack of order. But with Pd-extended, the aim is to have a clean, standard library mechanisms. There is much work to be done, but its usable now. And quite frankly, these days all Pd objects I write are organized to work in the structure of Pd-extended. I see little or no reason to do otherwise.
We need to think of Pd as a common platform, not as just a collection of code you find from wherever, and assemble however into some cobbled-together thing that isn't the same as anyone else's install.
.hc
Just an opinion as a PD instructor.
c
.b.
________________________________________________________________________ ____
"The arc of history bends towards justice." - Dr. Martin Luther King, Jr.