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.
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).
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" ?
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" ?)
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...
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