--- On Sun, 8/1/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] abstraction setting its own arguments To: "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at Date: Sunday, August 1, 2010, 7:40 PM On Sat, 31 Jul 2010, Jonathan Wilkes wrote:
- the magical [inlet] message on loadbang is weird and
will cause a
crash in winxp if you happen to remove the
abstraction's inlet.
You mean you don't get the following error message ?
« error: [args hello (world a 42) *] inlet 0 method loadbang: can't send init-messages, because object has no [inlet] »
- sending output from [args] on loadbang is redundant
when
[loadbang]-[args] is so trivial.
No, it just crashes. 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. Why did you choose to do that?
lots of shortcuts are trivial individually, then pile up to make a difference.
The problem with auto-[loadbang] in args is that [loadbang] order is a dangerous thing (which I forgot to think about when designing that part of [args]... not sure what to do with it now... a bit hard to undo).
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.)
Maybe you could have another object with a different name like [getargs] that doesn't do the loadbang.
Is there anything [args] can currently do that
wouldn't be possible by taking an "anything" at its inlet?
What would be the meaning of that "anything" ?
I don't know why I said "anything" and not "list". I guess I was thinking that $@ expands to an anything and not a list (unless the first arg is a float). But as you show, it would most likely arrive at [args] as a list anyway...
you mean plugging [loadbang]-[list append $@] into it ?... maybe it would work, but it would be two more objects per abstraction, too. (and it wouldn't be a "anything". why "anything" ?)
Yes, in this case I would say "list".
But since I'm working on clarifying the docs...
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).
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. )
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."
Do any of these fit your definition of "anything"?
Additionally, your method of using commas to separate
named init values assumes that the pd programmer doesn't want to send commas as arguments (which I did want to do in my [expr] example).
I expect to add this feature whenever someone needs it :
[args *, nocommas]
would consider commas as non-special. Also :
[args *, nocommas, noparens]
would completely disable special parsing. But it's also possible that the syntax would be :
[args *, commas 0, parens 0]
a 0/1 attribute specified without a value defaults to 1. I haven't really thought about a rule for what is better, negative bools (names with "no" in them) when they sound good (mainly for exceptional cases), or positive bools all over.
So what I'm saying is that your [args] doesn't fit my
needs, and $@ wouldn't fit everyone's needs, but $@ + [args]
- [other_parsers_as_needed] would fit the maximum number of
needs
You know, passing [loadbang]-[list append $@]-[args] isn't making [args]'s code any shorter than with an autonomous [args] as it is now.
And then, for the handling of abstractions' properties dialogues, I'm going to do something rather close to a list-method for [args], without doing it : I'm going to use [setargs] just before re-banging the [args]. It's the only way I can think of using [args] with an input that is not just the original arguments of the abstraction-instance...
Why are [args] and [setargs] two separate objects?
without burdening the users with learning a completely
different way of getting args every time they want to do something different with them.
I'm all for adding $@ to pd-extended, but by itself, its inclusion in pd-extended doesn't seem like a reason to change anything in [args] at all. In any case, if you feel like $@ has to be included in pd-extended, that's something you have to talk to Hans about.
_____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801