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 :) cheers Miller 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: > > Thus: > [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. > > -Jonathan > > > > > > >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. > > > >fgmasdr > >IOhannes > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.12 (GNU/Linux) > >Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > >iEYEARECAAYFAlGR7BAACgkQkX2Xpv6ydvTOrgCdES/Zb8By5xaHwMC9lTCsN350 > >SIwAoNeupdYrV4mKwfBmqFM7z+UPGfh4 > >=36tV > >-----END PGP SIGNATURE----- > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
