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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
