Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
Of course, i was not going to question that. However, i consider it sub-optimal, that several object classes treat the very same data type so differently. The fact, that you have to learn every single object behaviour does certainly not justify, that [list 45(->[symbol] = 'symbol list', whereas [list 45(->[symbol\ = 'symbol float'. This difference in behaviour seems pretty arbitrary to me (please correct me). I'm not getting any smarter by knowing this.
Personally I consider this a kind of inconsistency bug.
To me, it is not even clear, when data types are converted, in cases when conversion happens at all. Does it happen at the 'inlet', or the 'outlet'? at both?
I happens in between: Every Pd objectclass can define different methods for different kinds of messages coming in. Or said in another way: You can select what behaviour you want an object to show by prefixing your messages with a certain "selector" - this is where the word "selector" comes from. For example a [delay] object has these behaviour methods on the first inlet:
a) send a bang after the time of its stored delay time b) set the stored delay time to x and send a bang after that time c) cancel any scheduled bangs
You select behaviour a) by sending a "bang" message, you select b) by messages with selector "float" and c) with selector "stop".
On the C-code side, this is handled with messages like delay_bang(), delay_float(), delay_stop() that get called according to the selector. If you write an abstraction, you can mimick the same things with [route float bang stop]. You've all done this already.
What an object produces on the outlet-side also is defined by the object: From an abstraction, you can send out bangs, symbols, meta-messages etc. Same with C-objects: There are Pd functions like outlet_float(), outlet_symbol(), outlet_anything() that an external's author can use to produce any kind of output. This includes the possibility to write objects that behave "strange" or inconsistent. But these inconsistencies are not caused by the message mechanism behind it, they are caused by the object's author, either deliberatly or not.
Knowing this would probably make me any smarter and would allow me to make predictions about how certain objects behave in certain situations.
I hope you're a bit smarter now, but probably you still cannot make predictions. :)
Thinking of the the [symbol] vs. [symbol\ and the [route] example (you mention below), one is just left with trying out the different cases and remember them.
Or thinking about making a bug report/feature wish.
Ciao
Frank