--- On Mon, 8/2/10, Mathieu Bouchard <ma...@artengine.ca> wrote:
> From: Mathieu Bouchard <ma...@artengine.ca> > Subject: Re: [PD] abstraction setting its own arguments > To: "Jonathan Wilkes" <jancs...@yahoo.com> > Cc: pd-list@iem.at > Date: Monday, August 2, 2010, 6:09 PM > On Mon, 2 Aug 2010, Jonathan Wilkes > wrote: > > >> « error: [args hello (world a 42) *] inlet 0 > method > >> loadbang: can't send init-messages, because object > has no > >> [inlet] » > > > > No, it just crashes. > > 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. > > > But my bigger point is that it's really confusing > behavior for messages to be coming out an inlet at loadbang > time when nothing is actually connected to that inlet. > > 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. What if the abstraction in question doesn't have any xlets, but the user wants to use key/value pairs? 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. It might be something relevant to the GFDP, so I'll send it to you after I flesh it out. > > > Why did you choose to do that? > > Because [args] used to have a right outlet to be connected > to the top left [inlet] and it would always go across the > whole patch in some ugly way. I could have made it left > outlet instead, but figured out that if I could save a bit > of boilerplate (usually a [t a] and two more wires) in every > abstraction, I'd have that much less in every abstraction, > and I wouldn't have to verify all abstractions to make sure > that they support the init-commas. > > > Exactly. The clean patching solution for multiple > loadbangs is pretty easy: [loadbang]-[t b b b etc.] . (I > actually used that even before thinking about the problem of > [loadbang] order because it just seemed like a simple, > readable way to do it.) > > That's not the only well-ordered one : you can do > clear-looking partial ordering of loadbangs by using > subpatches (with nesting or not). All subpatch [loadbang]s > are guaranteed to be finished before their immediate > parent's [loadbang]s. > > > Maybe you could have another object with a different > name like [getargs] that doesn't do the loadbang. > > I may as well do search-and-replace on all of GridFlow. I > shouldn't care so much about backwards-compatibility when > not only other people don't contribute abstractions to GF, > but also, there's no one even saying something like « I > use [args] ». Then why bother. > > But at this point, my idea of it is to make it a > comma-option in [args] : > > [args foo bar *, noloadbang] > > and then think some more before getting into anything not > backwards-compatible. > > > The word "anything" seems sometimes to be used in > opposition to the list message, to refer to a multi-element > message with a selector other than "list" (or a > single-element message with selector other than bang, > symbol, float, or pointer). > > bang is not a single-element message : it has no $1. Right. Other messages consisting of only a selector are part of this definition, too. > > > 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). > > > And at further other times, it seems like it means > "other than x/y/z, anything", as in, "other than 11 reserved > selectors, you can send anything to [bng] and it will > trigger a bang." > > this is why method <any> appears last, for a given > inlet or outlet. Ok. I just explain it explicitly for those objects that require it. > > > Do any of these fit your definition of "anything"? > > No. The one I mean here is more like : if you put $@ alone > in a message box, you'll get "an anything" in the sense that > the possible values of $@ make most any message possible. > This includes the case where the value of $1 is "list", in > which case the $1 of the output will be the $2 of the input. > (In effect, this would be a shortcut of [list trim].) How is your definition different than my 2nd one above? > > Whereas you get "a list" if you write "list $@" in it > because you can only make list-messages that way. > > > Why are [args] and [setargs] two separate objects? > > Didn't really think about it. Any ideas ? 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. > > I suppose that there would be a point soon when I will have > a better idea about what to do, but I only _started_ using > [setargs] very recently, so, I don't know yet. > > _ _ __ ___ _____ ________ _____________ > _____________________ ... > | Mathieu Bouchard, Montréal, Québec. téléphone: > +1.514.383.3801 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list