signal objects don't follow ~ naming convention
danomatika opened this issue · 26 comments
Why aren't the signal rate objects named with a ~? aka [e_tremolo]?
It's to make typing easier and faster - the ~ seemed to be hard to access on e.g. Mac keyboards.
I guess I can see that on the German keyboard ... too bad it breaks the naming convention with all of pds built in objects though. Easier for beginners to differentiate between signal and message objects.
@footils ~ isn't hard to get on Mac keyboards, and it's a strong convention in PD and Max that all signal objects have names that end in ~. So this really should be changed.
I'd be willing to add wrappers for existing objects for backwards compatibility and update naming in the help patches, etc.
@danomatika That makes some sense. I'll admit that I've been considering making a large pull request that both adds the ~s and gets rid of the ugly type prefixes, replacing them with either ~s or directory names.
Well no. I think you're mixing some things up. s_* are synth objects and the prefixes are fundamental to the naming conventions of the library. I can agree with adding ~ but not with changing the overall naming.
Also, any PR like that won't go very far without some sort of discussion. Perhaps the authors had a reason for choosing it. What may seem "wrong" to you or I could simply be a style preference in the end.
I'm also following the naming conventions with my own library which works with rjlib: https://github.com/danomatika/rc-patches/tree/master/rc
@danomatika While I like the functionality in rjlib, I think the naming conventions are at odds with both Pd conventions and general programming practice, so I favor changing them wholesale. Pd has osc~, not s_osc; likewise, I think rjlib should have pinknoise~, not s_pinknoise. If we use the ~, the s_ becomes entirely unnecessary (because it means just about the same thing) and should be dropped.
If it can't be dropped, then I favor making it into a directory namespace, so that instead of s_pinknoise~, we have s/pinknoise~ or even synth/pinknoise~. My thought here is that if I'm using a lot of s_* objects in a particular patch, then I have to type the s_ each time, whereas if s is its own directory, then I can use an import object to add the s directory to the search path so I don't have to type s/ each time. Also, this would help make the code easier to browse, I think.
@danomatika ...so no, I don't think I'm mixing things up as you suggest. I fully understand what the type prefixes represent; I just think they're a mistake.
Not everyone uses import nor do they want to add multiple paths when one will suffice. Also, one of the main reasons for using prefixes is to avoid name clashes. For instance, there is already a [pinknoise~] in Pd-extended.
Not everyone uses import
How do you load libraries, then?
nor do they want to add multiple paths when one will suffice.
There is no necessity to do that. The nice thing about my proposal is that if you want to keep typing s/pinknoise, you can. But I don't, so I can do import s and just type pinknoise.
Also, one of the main reasons for using prefixes is to avoid name clashes. For instance, there is already a [pinknoise~] in Pd-extended.
Then, as before, don't import, and continue to specify s/pinknoise explicitly. Using directories as I am suggesting lets the patch developer import (and omit prefixes) or not import (and type prefixes explicitly). Using prefixes hard-coded into the object names (as rjlib currently does) forces everyone to use the latter option whether or not they want to.
In other words, what I am proposing with directory namespaces lets you work exactly the same way you have been doing (except for replacing _ with /). But it provides an alternative for those who want it.
How do you load libraries, then?
[declare -path path/to/rjlib]
There is no [import] in Pd-vanilla / libpd.
@danomatika OK, point taken. But I think everything I'm saying about import is equally true if you substitute declare.
Sure but I'd also point out that there are probably tons of existing projects using rjlib that might be broken with a bulk name change. However, many if not most of those might be like RjDj apps where they are using a bundled copy of rjlib.
In any case, it's up to Frank and Joe in the end.
Your point that subfolders aren't really that much different character wise is definitely true. I was also thinking of using l_ for list abstractions so u_listrandom would become l_random.
Also, I need to make a PR for the updates I have sitting on my computer before I/we change too much.
Sure but I'd also point out that there are probably tons of existing projects using rjlib that might be broken with a bulk name change.
Of course that's true. However, that's probably an argument for versioning RjDj (Git tags and the GitHub release system?) rather than not making a change that otherwise seems justified.
However, many if not most of those might be like RjDj apps where they are using a bundled copy of rjlib.
Also a good point.
I was also thinking of using
l_for list abstractions sou_listrandomwould becomel_random.
I think type prefixes are very much against the spirit of Pd, no? None of the standard libraries included with Pd or Pd-ext names things this way.
I was also thinking of using l_ for list abstractions so u_listrandom would become l_random.
I think type prefixes are very much against the spirit of Pd, no? None of the standard libraries included with Pd or Pd-ext names things this way.
The spirit of Pd is do what you want more than anything else. Good luck trying to make a convention.
None of the "standard" libraries use prefixes because most were written when there was a relatively small set of objects. Like any programming language, global namespaces are fine when there aren't that many names but get unmanageable as they are grow. 4 years ago or so, using prefixes was a reasonable solution.
Maybe now that things like [import] and [declare] are around, plus Pd-extended not including all libs by default at startup will help for a transition. When I started using Pd in 2005, I used prefixes for my lib because basically there was no guarantee I'd end up loading my own objects when there were shadows out there.
I'd also point out that GEM and Jitter in Max both use prefixes (jit.* & gem_*).
Plus imagine the day the Pd gui has autcompletion, you could get a list of all rj synths by just typing s_.
The spirit of Pd is do what you want more than anything else. Good luck trying to make a convention.
Every programming language or environment develops idiomatic conventions, even if they're semiconscious. See http://puredata.info/docs/developer/CodeGuidelines for what appears to be an attempt to document and encourage some consistency (strangely, it doesn't directly mention the ~ convention—perhaps that was considered to be too well known to require mentioning?).
Note in particular the following paragraph from that page:
the geiger namespace [that is, the use of the
dir/objectform] makes class name prefixes like "sp_" unnecessary. - A better solution would be a more descriptive name if you want to differentiate your class from another class with the same name.
Maybe now that things like [import] and [declare] are around, plus Pd-extended not including all libs by default at startup will help for a transition.
Right, I'm relatively new to Pd, but I did know that library loading has been changed around a bit in the last few years. This makes sense.
I'd also point out that GEM and Jitter in Max both use prefixes (jit.* & gem_*).
Interesting (and I didn't know that because I've hardly used Max at all). But note that GEM for Pd does not use prefixes, which suggests that this is a difference between Max and Pd style.
Plus imagine the day the Pd gui has autcompletion, you could get a list of all rj synths by just typing
s_.
Srsly? First of all, Pd doesn't have autocompletion, so we probably shouldn't try to design for it a priori. Second, since Pd doesn't have autocompletion yet, we can't know how it would work. It's easy to imagine an autocompleter which would work with s/ as well as with s_. Third, if I want a list of synths, I'd be more likely to look in the help browser...
Or did I miss a joke here? :)
sigh
See http://puredata.info/docs/developer/CodeGuidelines for what appears to be an attempt to document and encourage some consistency (strangely, it doesn't directly mention the ~ convention—perhaps that was considered to be too well known to require mentioning?).
Sure there is that document. But that doesn't mean people follow it, nor does it apply to all the libraries written before it existed. You're assuming there is a coherent community that works together and agrees on such things and, in my experience, Pd development is much much more nebulous than that. "Anarchy" is the applicable word, not "organization". It's not that I don't agree with you about naming etc, I'm just being pragmatic and perhaps trying to pass that on. For the standards that exist, they have grown very organically as opposed to from a top-down decision making process.
But note that GEM for Pd does not use prefixes,
gemwin, gemhead, gemlist, glsl_fragment, part_render, pix_color, GEMglPushMatrix, GEMglPopMatrix, etc with:
- gem: main gem objects & types
- glsl_: OpenGL shading language objects
- part_: gem particle system objects
- pix_: gem pixel based objects
- GEM: OpenGL api wrappers
- etc
Srsly? First of all, Pd doesn't have autocompletion, so we probably shouldn't try to design for it a priori.
https://github.com/gusano/completion-plugin & http://puredata.info/downloads/completion-plugin
Or did I miss a joke here? :)
I think you did.
I think I'm responding alot not because I disagree with what you're saying but mostly with how you're saying it. It's perhaps a bit grating that you both admit to being a new user while at the same time telling us how things should be. Frank, the original author of much of rjlib, might simply prefer using prefixes as opposed to folder names. Why should he change it if that's his preference? In the end, it's not really that big of a deal and is why I chose not to push further on the ~ naming when updating my patch library because I was happy to have at least one naming convention to try to follow, that and the fact that my lib interoperates with rjlib now. I'd much rather move forward by adapting to an existing standard than trying to force an ideal on everyone else. In my experience, that's just how it is in the Pd community.
There are those of us who have spent ridiculous amounts of time on Pd in general and have hashed & rehashed those kinds of things for years, in the end admitting that, perhaps, things will never be perfect in this kind of project where there is not really one centralized decision maker. People work the way they want/need to and that's fine. It's doubly cool that they decide to release that work. It's not an ideal situation but it's fine, as the Edison saying goes: "Better is the enemy of good."
But that doesn't mean people follow it, nor does it apply to all the libraries written before it existed. You're assuming there is a coherent community that works together and agrees on such things and, in my experience, Pd development is much much more nebulous than that. "Anarchy" is the applicable word, not "organization".
I understand that.
It's not that I don't agree with you about naming etc, I'm just being pragmatic and perhaps trying to pass that on. For the standards that exist, they have grown very organically as opposed to from a top-down decision making process.
Oh, of course. But (in my experience) the way "organic growth" takes place is through discussions such as we are now having.
And about the GEM prefixes: I was referring to the namespace prefix that you had pointed out in GEM for Max. You're right that GEM for Pd uses certain (inconsistent?) prefixes of a different style.
https://github.com/gusano/completion-plugin & http://puredata.info/downloads/completion-plugin
Cool! It never would have occurred to me to even look for anything like that.
I think I'm responding alot not because I disagree with what you're saying but mostly with how you're saying it. It's perhaps a bit grating that you both admit to being a new user while at the same time telling us how things should be.
I'm not so much meaning to tell you how things should be, and I'm sorry if I came off that way. Rather, I saw what I perceive as something that could be improved, so I applied my usual process in open-source projects: be bold and propose improvements. If my proposal isn't worth implementing, or if it needs further discussion, that's fine.
Frank, the original author of much of rjlib, might simply prefer using prefixes as opposed to folder names. Why should he change it if that's his preference?
Why should his preference be the only guide for anyone who uses rjlib? I think there's value in having a more or less consistent set of idioms, at least in libraries meant for public use.
I'll say also that while I'm relatively new to Pd, I've been a professional programmer in a variety of languages for many years. One of the things I've come to believe is that programming is less about preference and more about finding the right way to do something, given a certain set of constraints. (I know that's controversial, but I think I've always wound up with better code when I've approached programming problems from that mindset.) The constraints, and thus the right approach, often change over the life of a project. That's why we refactor code.
There are those of us who have spent ridiculous amounts of time on Pd in general and have hashed & rehashed those kinds of things for years, in the end admitting that, perhaps, things will never be perfect in this kind of project where there is not really one centralized decision maker.
I'm involved in lots of programming communities where there isn't one centralized decision maker. In each case, a standard emerges, perhaps not consciously. I'd be really surprised if the Pd community were any different—unless Pd developers simply don't talk to each other as much as developers in other languages...
People work the way they want/need to and that's fine. It's doubly cool that they decide to release that work. It's not an ideal situation but it's fine, as the Edison saying goes: "Better is the enemy of good."
But nearly any code can be improved. I think that responding to a proposal by saying "better is the enemy of good" fundamentally misses the point. We have something good; I'm making a proposal to make it better. If you disagree that my proposal would improve things, I can accept that (hence this discussion). But it sounds like you're using that quote to mean "hey, let's not worry about making things better"—and that's a viewpoint that I emphatically disagree with. If something can be made better (for an appropriate definition of better), then shouldn't it be made better? Otherwise everything succumbs to inertia, bitrot, and mediocrity.
…and also, I've been writing way too much on this issue. There's probably a more appropriate forum for this discussion…
Sure. But I understand exactly where you're coming from, it's just that I keep banging my head when trying to change things. Just follow this recent thread: http://lists.puredata.info/pipermail/pd-list/2014-02/105903.html
But it sounds like you're using that quote to mean "hey, let's not worry about making things better"
That's not what I mean at all. Maybe more like, let's find a sustainable way to make changes and perhaps focus on the things that are more important, perhaps this issue is not currently one of them.
@danomatika I'm not sure what that thread has to do with the present discussion, since it seems to me that we're talking about library development, and that's completely independent of Pd itself. I will note, however, that your behavior here seems quite reminiscent of what you're complaining about over there. :)
I will note, however, that your behavior here seems quite reminiscent of what you're complaining about over there. :)
That's what I mean. It's easy to burn out trying to change things, even for the better.
@danomatika So why are you acting in the same way you're complaining about when other people do it? I don't follow how burnout applies here.
You're right,I'm not explaining myself in any way that makes sense. I'm closing this issue and you can reopen another so Frank and Joe can actually answer.