<div dir="ltr">Howdy,<div><br></div><div>I think what you are going for is this?</div><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">class Foo</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">{</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> 1.0 => float _f;</span><br style="font-family:arial,sans-serif;font-size:13px">
<br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> fun float foo(float f)</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> {</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> f => _f;</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> return _f;</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> }</span></div><div><br></div><div> fun float foo()</div><div> {</div><div> return _f;</div><div> }</div><div><span style="font-family:arial,sans-serif;font-size:13px">}</span><br style="font-family:arial,sans-serif;font-size:13px">
<br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">Foo f;</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">42.0 => f.foo;</span><br style="font-family:arial,sans-serif;font-size:13px">
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><<<"foo", f.foo()>>>;</span><br style="font-family:arial,sans-serif;font-size:13px"></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span style="font-family:arial,sans-serif;font-size:13px">The canonical ChucK setter/getter paradigm is two functions, one each for setting and getting. This is more or less uniformly adhered to by the built-in ugens. Calling f.foo (without parentheses), if foo is a function, is fairly atypical, since it evaluates to an internal memory address that doesn't have much significance at the ChucK code level. That being said, atypical use cases still should not be met with a crash, so thanks for bringing this up! </span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">spencer</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 28, 2013 at 3:50 PM, Kassen <span dir="ltr"><<a href="mailto:signal.automatique@gmail.com" target="_blank">signal.automatique@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Jan 28, 2013 at 05:22:15PM -0600, Michael Heuer wrote:<br>
><br>
> Yes, odd.<br>
><br>
> That pattern is my best attempt to make classes/chugens/chubgraphs<br>
> look more UGen-ly, in that you can use value => foo notation and<br>
> f.foo(value) notation. Typically in my use cases there are side<br>
> effects in the function call in addition to setting the value of the<br>
> field, so just doing value => f._f in the example above would not be<br>
> sufficient.<br>
><br>
<br>
</div>Yes got it. In a way this is a inconsistency;<br>
3 => my_gain.gain; //works<br>
3 => my_class_instance.funny(); //has to be done like that.<br>
<br>
I agree with you that this is inconsistent to the point where it might<br>
bother us. I'd go as far as claiming that the "=>" operator is already<br>
so overloaded that the only way to make sure ChucK will stay<br>
consistent is to also allow for user-defined further overloading. I<br>
can see why serious CS people might hide under the nearest furniture<br>
over this idea, but I'm sticking to it.<br>
<div class="im"><br>
><br>
> Thanks. If you're not breaking ChucK or blowing up a channel on your<br>
> mixer occasionally, you're not trying hard enough. :)<br>
<br>
</div>IMHO mixer channels on mixers beyond the "bargain" level should not<br>
blow either, at least not when fed signals somewhat similar to<br>
reasonable audio ones. Mistakes in code and patching can and will<br>
happen. We expect error handlers and mixers to deal with those; I<br>
expect the pre-fader listen function to tell me when I patched<br>
something wrong *before* I open the fader and risk damaging a rack of<br>
amps, stack of speakers and potentially the ears of a few hundred<br>
people; that's what the mixer is for, aside from mixing and routing.<br>
Same thing with a error-handler. Error-handlers should be able to take<br>
abuse, that is what they are there for.<br>
<br>
Before we are at that level we clearly need to go through this phase<br>
where any advanced ChucK project will yield bug-reports and we need<br>
the kind of ChucKist like yourself who'll file them. :-)<br>
<br>
<br>
Yours,<br>
Kas.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
chuck-dev mailing list<br>
<a href="mailto:chuck-dev@lists.cs.princeton.edu">chuck-dev@lists.cs.princeton.edu</a><br>
<a href="https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev" target="_blank">https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev</a><br>
<br>
</div></div></blockquote></div><br></div>