Not really a suitable category for the TB2 stuff, so I popped it in here as it seems the most suitable.
One thing that occurred to me while looking through (all the exciting) new additions is that the syntax being used for more objects is much closer to the very first iteration of TB1 (which led to some long discussions…).
So messages like transformer dataset1 dataset2, for me, are very much back in this territory, and break from the rest of the TB1 syntax like source buffer1, destination buffer2, bang, where there is some legibility to what is happening, as well as the ability to set the source/destination from separate parts of the patch, as well as being able to bang the process.
Granted, much of the database-management in TB2 doesn’t require these much longer strings, but they very well might at some point. But more importantly, programming with these objects now requires two very different ‘house styles’ to messaging. As it is, the paradigm for TB2 is very different anyways (objects-as-functions), so that’s pretty different, but the variations in syntax and messaging seems less pleasant.
Yes, the difference in paradigm is indeed at the heart of this. In toolbox one objects, the whole of something’s state can be encapsulated through its attributes, and this is what governs the paradigm for communicating with them: <set a thing>, <set another thing>, process
For Dataset and friends, state can’t be encapsulated wholly through attributes: a lot of it is necessarily internal to the object itself (e.g the set of relationships that defines a KDTree), and much of the functionality involves either computations that build that state (fit) or use already computed state to produce changes in data (transform, predict).
However, to me, both of these seem ‘in-paradigm’ for Max, and neither more or less legible from that perspective.
What I meant more was having trigger words that designate what’s happening.
So something like transform dataset1 dataset2 could easily be transform source dataset1 destination dataset2 while still keeping everything else the same. Granted it’s still different from having the comma separated things, but since the intention appears to be that both toolboxes will be merged at some point, while using the singular toolbox you will have to jump around between syntax/styles while doing a single task (since generally speaking, doing data stuff will also be coupled with doing decomposition stuff, so in a larger/contextual patch, there won’t be as clear a hierarchical separation between the TB1 processes and TB2 ones.
I guess this is a convention established by @a.harker with entrymatcher and descriptors, that message arguments get their own sort of pseudo-attributes. Lamentably, it’s not at all easy based on the architecture we have at the moment. The Max wrapper doesn’t know the names of any of the arguments it expects for messages (it just dumbly passes stuff on), so we wouldn’t be able to do much more than provide a false sense of security: i.e., you couldn’t change the order of these tagged things, and the wrapper wouldn’t know when you’d made a mistake or not.
Don’t get me wrong: I, too, like the principle of code being as self-documenting as possible, it’s just that the normal idiom for Max messages doesn’t do this. I’ll have a think: it might be that dealing with some others limitations of the current messaging code lets us improve matters.
