On 05/15/2013 03:15 PM, Ivica Ico Bukvic wrote:
On 05/14/2013 02:49 PM, Miller Puckette wrote:
Interesting idea. I agree that a non-lazy dev could just make argument strings serve the same function (and sometimes it's good to see all the args up front to prevent unnecessary allocations or computation).
Here's a thing to think about - how could abstractions (as opposed to externs) catch and use mesages separated by commas? There are lots of things abstractions can't do cleanly (like have variable numbers of inlets/outlets) and perhaps it could be helpful to use after-creation messages somehow for this. (I've always been nervous about the widespread use of self-modifying patches to fill this need :)
[args( | [canvasinfo] |
That is, whatever mechanism is used to parse the arguments to an object
box would be the same used by the "args" method of [canvasinfo]. So
you'd get an initial list of args to the outlet followed by a subsequent
message to the outlet for each comma separated message. (I suppose
"rawargs" would be a desirable method to add as well.) I need to look
back at Gridflow, because matju already implemented comma separated
syntax. All I remember is that he had an object which would send the
comma separated messages to the leftmost [inlet] which I didn't like.
But I don't know how it worked in object boxes, so I'll have a look.
As for "after-creation" as a general issue-- I'm sorry but it requires [initbang]. There's just no way around it. You can call it a different name, or you can hide it in args of a revised [loadbang] or implement it in whatever manner you want but that is the solution, it's been implemented, and it works.
Moreover, we cannot assume that every "after-creation" job which needs to happen inside abstraction can be triggered by a user-specified, comma-separated message. Easy example: imagine an object that sprouts an extra inlet depending on whether or not an argument was actually provided (like [select]). You don't want to force the user to type [someobject, I don't have any args].
I'm sure there are other examples that don't even have to do with arguments at all-- IOhannes has written about them somewhere on the list. The point is that you cannot restrict "after-creation" message-passing functionality to the domain of comma-separated arguments. You simply need a _general_ way to output a bang after all the objects inside the abstraction have been created. Though comma-separated messages to abstractions depend on that, they are themselves a separate issue.
-Jonathan
cheers Miller
This may be a totally stupid idea but here it goes anyhow... What about creating a special nlet object that can dynamically change the number of nlets (in or out depending on a flag given) and issue command to gop object to redraw itself upon update? Doesn't seem to hard to implement but it does seem a bit unconventional, if you like...
Well to be honest if you don't want to dynamically instantiate objects, then what other way is there aside from this approach?