On May 7, 2006, at 12:10 AM, Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
This is a different problem because messages and lists can't be
unified without making another problem appear elsewhere. If every message
is seen as a list then there is no way left to tell an object to do something special because all possible messages get already seen as data. I've already explained this in great detail on pd-list and/or pd-dev.
Think of the "set" method for example.So I think that in the message-vs-list case, if there are obscure problems, they should be transformed into clear problems by
teaching them to every pd user.And also to developers: Some of the annoyances with list- vs. "meta"-messages are introduced by externals like those inherited from Max: [prepend] in all or most of its versions except [list prepend] or the zl-family or - in a different way - [OSCroute], because these output a meta-message even when they receive a proper list-message and thus may introduce unwanted side effects later in the processing chain if users aren't aware of this.
AFAIR Miller's objects all work in something one could call the "list-message domain", which successfully prohibits these side effects from occuring, which makes list-processing a very comfortable thing again. If needed, translating a list-message to a meta-message is trivial, and generally this translation only is needed directly in front of an object when a meta-message is needed to access a method of this object.
I agree that Pd objects should not be clones of max objects in this
situation, and keeping things in the list domain probably makes the
most sense. But Pd is not entirely consistent in this. One key
example for me is that [route list] does not always output a list.
(Yes, I know, sore subject perhaps).
.hc
"The arc of history bends towards justice."
- Dr. Martin Luther King,
Jr.