[PD] bang vs empty list

[IOhannes m zmoelnig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

i guess i'm missing something, but...

On 2013-02-28 00:38, Charles Z Henry wrote:
> Each class has methods that can be looked up by symbol.  At some
> point after the class has been created, you could check the class
> has no bang method, and if so, add the default bang method.  Only
> built-in classes are loaded when pd starts up, so if you load a
> class later, it would not have the default method.

each object has a default method, namely the defaul catch-all ("aka
"anything") method, that will print "no method for <foo>".
not having an explicit "bang" method, will defer the "bang" message to
this catch-all method.

> 
> If you wanted it done at setup time, you would have to modify the
> function that calls the setup function (I don't know what it is or
> how it's done--please tell me) so you would follow the setup
> function and add default methods.

not sure whether i totally understand what you mean by "setup time"
(and "setup function") here.
the function that calls the setup function does not do anything
special (it just calls an entry point in a dll). especially, it does
notmake any assumptions what this setup function is going to perform
(though in most cases it will register some classes).

so, the only function that needed to be changed would be the generic
class-creator function class_new().

nevertheless i don't see what this would solve with respect to the
current behaviour.

i can imagine that the problems you are trying to solve are caused by
Pd's automatic conversions between different types (e.g. [list 12( and
[float 12().
if you removed all those conversions, you would immediately get your
"desired" behaviour.
and people would start complaining why the following gives an error
"[sin]: no method for 'list'".
[1 2 3(
|
[list split 1]
|
[sin]

this can of course be fixed by simply adding an explicit "list" method
to [sin], which does "the right thing".
but all the problems that arise because of the automatic message
conversion can already be solved by adding explicit methods for
messages you don't want to be autoconverted.



btw, i think something really nice to have would be per-object methods
(as oppposed to per-class methods). for this to work, the object would
need a copy of the class method table (rather than a reference).

fgamsdr
IOhannes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEvFakACgkQkX2Xpv6ydvS4vgCfa5l8LEuR8IhDQdqPtH/VE7qX
860An0vDf9w36U/I4qxD7si1pLX5CVT4
=9kvD
-----END PGP SIGNATURE-----