Ok, list... I realise this may be edging on dangerous teritory but I was just fooling around with the miniaudicle and some filters and had to type this; sawosc s => TwoPole f => dac; This works perfectly; that's not the problem. My problem is that it's "TwoPole" and not "Twopole" or "twopole" and yet it's not SawOsc but sawosc. I realise this is because we are borowing from the STK and also using new stuff but.... Well, to be honest I'd realy prefer a consistent use of caps. Frankly I'd be in favour of simply making it all lowercase or at least a consistent use of case because this -to me- is hard to remember. Yours, Kas.
Classes from STK (The Synthesis ToolKit in C++) obey the original caps convention. New classes that are unique to ChucK area all lower case. PRC On Sat, 5 Aug 2006, Kassen wrote:
Ok, list...
I realise this may be edging on dangerous teritory but I was just fooling around with the miniaudicle and some filters and had to type this;
sawosc s => TwoPole f => dac;
This works perfectly; that's not the problem. My problem is that it's "TwoPole" and not "Twopole" or "twopole" and yet it's not SawOsc but sawosc.
I realise this is because we are borowing from the STK and also using new stuff but.... Well, to be honest I'd realy prefer a consistent use of caps. Frankly I'd be in favour of simply making it all lowercase or at least a consistent use of case because this -to me- is hard to remember.
Yours, Kas.
On 8/5/06, Perry R Cook
Classes from STK (The Synthesis ToolKit in C++) obey the original caps convention. New classes that are unique to ChucK area all lower case.
Yes, I realised this, in fact it's nice to recognise bits from the book as ChucK ugens. However, for normal ChucK use there isn't that much difference between the two and where to cap and where not to seems fairly arbitrary from that perspective. Maybe it's just me being dyslexic again but every time the compiler complains I go "now what's wrong?" and have to remember this. To me it would seem sensible that if you go "TwoPole" then you also go "SawOsc". If I'm the only one who thinks this is odd/ confusing then I'll happily try to remember what bit comes from where but personally I'm in favour of languages being consistend and having as few exceptions as possible; natural languages are confusing enough as it is already. Just my perspective; nothing more. Kas.
Hi Kassen! Perry and I have been considering this consistency issue from a while back. Currently, all STK ugen's have uppercase convention. Also, all the non-UGen classes, like Object, Event, HID, Midi*, OSC* all use the same. In fact the base UGen class uses it. So it would be more consistent for the likes of sinosc, gain, sawosc, fullrect, impulse, etc. to also follow suit. Perhaps the way to go for now is to provide uppercase convention for the native chuck ugen's (SinOsc, Impulse, Gain etc), but also keep the lowercase versions (sinosc, impulse, others) for backward compatibility. It's extra stuff in the namespace for now, but overall that might make more sense. Thoughts? Best, Ge! On Sun, 6 Aug 2006, Kassen wrote:
On 8/5/06, Perry R Cook
wrote: Classes from STK (The Synthesis ToolKit in C++) obey the original caps convention. New classes that are unique to ChucK area all lower case.
Yes, I realised this, in fact it's nice to recognise bits from the book as ChucK ugens. However, for normal ChucK use there isn't that much difference between the two and where to cap and where not to seems fairly arbitrary from that perspective.
Maybe it's just me being dyslexic again but every time the compiler complains I go "now what's wrong?" and have to remember this. To me it would seem sensible that if you go "TwoPole" then you also go "SawOsc". If I'm the only one who thinks this is odd/ confusing then I'll happily try to remember what bit comes from where but personally I'm in favour of languages being consistend and having as few exceptions as possible; natural languages are confusing enough as it is already.
Just my perspective; nothing more.
Kas.
Perhaps the way to go for now is to provide uppercase convention for the native chuck ugen's (SinOsc, Impulse, Gain etc), but also keep the lowercase versions (sinosc, impulse, others) for backward compatibility. It's extra stuff in the namespace for now, but overall that might make more sense. Thoughts?
Agreed. That would make it consistend as well as keep old .ck files compatible; I'm all for it. My case is simply for consistency because I have a hard time remembering arbitrary (or aparently arbitrary) data. caling a two pole filter "TwoPole" makes sense; capitalising because it came from the STK is much harder to remember. Does that make sense? Yours, Kas.
Ge Wang wrote:
Perhaps the way to go for now is to provide uppercase convention for the native chuck ugen's (SinOsc, Impulse, Gain etc), but also keep the lowercase versions (sinosc, impulse, others) for backward compatibility. It's extra stuff in the namespace for now, but overall that might make more sense. Thoughts?
That sounds fine. -- peace, love & harmony Atte
Perry R Cook wrote:
Classes from STK (The Synthesis ToolKit in C++) obey the original caps convention. New classes that are unique to ChucK area all lower case.
That's a very clear cut definition/explanation. However from a users point of view I agree with Kassen, that this historic, implementational stuff is irrelevant. At least in such an elegant language as chuck. Changing this will break code, but better now than in a year (where the user base will be huge compared to now). Just my .01 -- peace, love & harmony Atte
participants (4)
-
Atte André Jensen
-
Ge Wang
-
Kassen
-
Perry R Cook