Hi Frank
Thanks a lot for giving me such detailed insight.
Am 26.11.09 09:24 schrieb "Frank Barknecht" unter fbar@footils.org:
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.
Ok.
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.
...
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.
Ok, i see. If i understand right, this would also make it possible to deliberately create a message 'list 23' at the outlet, which is probably converted to a 'float 23' by the next object's outlet (_if_ this next object's inlet knows what to do with the selector 'list'). Unfortunately, knowing this doesn't make me understand what happens here - for instance:
[list 23( | [print]
which produces simply '23' in the pd window. Now, does the message box object do some evaluation and effectively sends 'float 23' instead of 'list 23', or is the [print] that does some reformatting and treats single element lists as 'float' or 'symbol' messages?
Is there a way to know what goes through a connection wire?
Also interesting cases to consider:
[list velo( -> 'symbol velo' [float 12 34( -> '12'
But these inconsistencies are not caused by the message mechanism behind it, they are caused by the object's author, either deliberatly or not.
I see. Let me pick an example, which to me is not quite clear, which of the involved object classes should be considered buggy:
[foo 56(
|
[route foo]
|
[*~ ]
This raises an error: inlet: expected 'signal' but got 'list' Is it [route]'s fault not to spit out a message with 'float' selector, since obviously the message contains only a single element? Or is [*~ ] supposed to accept single-element-lists as well and raise only an error, when the single-element-list contains a symbol, but not a float?
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. :)
Hmm.. i guess, you're right...
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de