On Mon, 2 Aug 2010, Jonathan Wilkes wrote:
--- On Mon, 8/2/10, Mathieu Bouchard matju@artengine.ca wrote:
I suppose you can also find other situations in which GF crashes instead of reporting an error message ?
That's the only I've seen so far. I haven't used GF much yet.
That's quite a problem, because I can't think of anything that would make this error message any more crash-prone than the standard error messages you get in GF externals (GF abstractions are a different matter though, because then, many error messages would come from Pd instead).
It's confusing while you don't expect it. Once it's expected, it's not any more confusing than receive-symbols hidden inside IEMGUI properties dialogues.
But IEMGUI receive-symbols don't make any assumptions about whether or not there is an inlet in a particular canvas.
My comparison with IEMGUI is to mean that once you start with the supposition that every message travels along a wire, you hit one exception with [r]/[s] and it's fine, then you hit another exception with hidden implicit [r]/[s] inside IEMGUI and floatatom/symbolatom and it's fine as well, and then you hit another exception with [args] and I don't know why it would be less fine.
What if the abstraction in question doesn't have any xlets, but the user wants to use key/value pairs?
If an object has no need for an inlet, then it doesn't matter whether there is one at all.
And then, the point of key/value pairs in left inlets is to ensure that every attribute is settable at runtime in the same manner as it is settable in the objectbox. It is enforcing a standard by making it convenient to follow the standard. Thus, the perspective of [args] on key/values is that objects that use them should have an [inlet] so that those attributes can be reconfigured at any time if the user wants it.
I could add an option to make it differently (actually, backward-compatible with the older [args] that didn't do that yet) but I don't really see a purpose for which I'd say « yes, it's a good idea to make this attribute non-reconfigurable ».
Actually there's a particular doc-related example I have in mind that would benefit from key/values in the args but doesn't have xlets.
You know, if it's a GOP, then the [inlet] can be hidden by putting any GOP-visible component on top of it. the GFDP components such as [doc_i] and [doc_m] are covering the inlet-space, at least in run-mode (those two particular classes only do so in run-mode).
I'm actually also toying with the idea of adding inlets to [doc_m] and such, during the « GFDP rewrite », that is, some major change to GFDP that I expect would be the last big change. I don't know when that rewrite would happen. I'll try to make it as gradual as possible (simply because big changes are much harder to finish than the sum of their parts...)
It might be something relevant to the GFDP, so I'll send it to you after I flesh it out.
ok
At other times it seems to mean any message that would be accepted by the anything-method, which includes list messages as well as the other pd built-ins. (like [any], [send], [spigot], etc. )
What does that case exclude ?... only "loadbang" and "dsp" ? (but then, not even necessarily).
It includes those messages (well, maybe not "dsp" with signal objects-- that's special).
[loadbang] does not send to any objects that only have a anything-method. It only talks to objects that explicitly define "loadbang". Same for "dsp".
(In both cases, this is an exception in the sending, not the receiving, ... but that distinction doesn't even matter to a writer of externals, in which case all that matters is that class_addanything is not enough)
How is your definition different than my 2nd one above?
Oops... either there was no difference at all, or there was something very subtle and I forgot what it was.
An [args] that does both setting and getting would be somewhat analogous to a "luxury" message box. You use all the same messages to set the content, and sending a bang would output the content. The big difference I guess is that with args you can tell it default values to output if there are no args, which you can't do with a message box.
Right. That sounds like something to consider, for the future...
But also, another big difference is that it does a job of [unpack]ing, that the messagebox doesn't do. Therefore, in that case, to follow an analogy with the messagebox, it's ambiguous whether there ought to be a complementary implicit [pack] behaviour in [args], causing it to have as many inlets as it has outlets.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801