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:
- Dev makes methods someobject_foo, someobject_bar, someobject_blah.
- 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-----
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list