[PD] Pd Development "Reverse Kickstarter"
msp at ucsd.edu
Tue May 14 20:49:57 CEST 2013
Interesting idea. I agree that a non-lazy dev could just make argument
strings serve the same function (and sometimes it's good to see all the
args up front to prevent unnecessary allocations or computation).
Here's a thing to think about - how could abstractions (as opposed to externs)
catch and use mesages separated by commas? There are lots of things
abstractions can't do cleanly (like have variable numbers of inlets/outlets)
and perhaps it could be helpful to use after-creation messages somehow for
this. (I've always been nervous about the widespread use of self-modifying
patches to fill this need :)
On Tue, May 14, 2013 at 12:57:07PM -0400, Jonathan Wilkes wrote:
> On 05/14/2013 03:47 AM, IOhannes m zmoelnig wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >hi jonathan,
> >great ideas!
> >On 2013-05-13 23:26, Jonathan Wilkes wrote:
> >>* adding a function to make it easy to parse comma-separated
> >>A_GIMME args to an object as named args. Thus for [someobject foo
> >>1 2 3, bar 1 2 3 4, blah bee], there should be a function that can
> >>be used inside of someobject_new for which the author can ask for
> >>the "foo" args and retrieve "1 2 3" (maybe by returning the indices
> >>to the first and last arg of "foo"). That will match the syntax of
> >>message boxes and give external developers an easy and consistent
> >>way to do named
> >personally i would go for something much simpler when using comma-args:
> > [someobject foo 1 2 3, bar 42]
> >would translate to something like
> > [preinitbang]
> > |
> > [bar 42(
> > |
> > [someobject foo 1 2 3]
> Yes, that would definitely make it a lot easier.
> Two initial reactions:
> * in the current implementation, sending bad args to an object ends
> in a broken object. But sending comma separated args would not.
> * the law of clever laziness dictates that any external developed
> after such a change will simply refuse to accept any args at all.
> Using your example:
> 1) Dev makes methods someobject_foo, someobject_bar, someobject_blah.
> 2) Dev starts to code someobject_new and realizes he/she needs to
> check the first arg of the A_GIMME against "foo",
> "bar", and "blah". (I assume ",bar 42" isn't part of argv.)
> 3) Dev already wrote that code in someobject_foo
> 4) Dev is lazy.
> 5) Dev is clever.
> 6) Dev accepts no args and tells users to just put a comma after the
> object name if they want args:
> [someobject, foo 1 2 3 4, bar 42]
> will be the de facto standard for setting args in the new way.
> (Unless it's trivial like [float].)
> I think [sigmund~] would have looked like that if it used
> comma-separated args. Plus all the iemguis.
> It's not terrible, but it's a little odd. [someobject foo 1 2 3 4,
> bar 42] looks to a user like [I_get_your_args "here is an arg,"
> "here is another"] where [someobject, foo 1 2, bar 3 4] looks like
> [object1, object2 arg arg, object3 arg arg].
> Of course I could be misunderstanding what you wrote. Maybe you
> mean that "foo 1 2 3 4" are the positional args,
> and they always come right after the object name as they do now.
> Either way [creatorname, method arg, method arg arg]
> would be a common sight.
> >with [preinitbang] being executed immediately after the instantiation
> >of [someobject], so it's guaranteed that [someobject] is not connected
> >to anything yet (kind of the opposite of [loadbang]). [preinitbang] is
> >only here for illustrative purposes, and shouldn't exist.
> >it all boils down to sending initialization messages to an object
> >right after it was created.
> >the nice thing about this is, that it doesn't require *any* changes on
> >the object's side in order to be able to use it out of the box in
> >*most* cases.
> >i've been thinking about implementing this for some time now (though i
> >never found any time to do it)...i just wanted to through it into
> >discussion before there are several competing uses of comma-separated
> >A_GIMME args.
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.4.12 (GNU/Linux)
> >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >-----END PGP SIGNATURE-----
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
More information about the Pd-list