[PD] abstraction setting its own arguments

[Mathieu Bouchard]

On Mon, 2 Aug 2010, Jonathan Wilkes wrote:
> --- On Mon, 8/2/10, Mathieu Bouchard <matju at 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