[PD-dev] initbang and friends WAS: run-up to release 0.43

[IOhannes m zmoelnig]

On 2010-08-23 17:33, Hans-Christoph Steiner wrote:
> 
> Yeah, we definitely don't want [initbang] to be used too often, I can

i would also like to state, that we shouldn't use [metro] too often.
reversely, one cannot use [trigger] too often.
so Pd should print out a warning if there is no [t] in the patch
whenever it is saved.

> understand that.  I just differ with how we should deal with the
> problem.  I think it should be handled in the documentation rather than
> making the programming part more complicated.


seriously, i don't see so many drawbacks with [initbang].
the biggest issue right now, is that there is no [initbang] in Pd-vanilla.
this makes patches using [initbang] incompatible with Pd-vanilla.
once it was included, this issue would become nought.

> I could see the initbang help path having a section called "When to NOT
> use initbang" then it would include your example below with the example
> of how to use it.  

hmm, i guess some words are missing here, as i don't understand why we
would include an example of how to use it in the "when to NOT use it"
section.


anyhow, in most cases [initbang] can be used as a replacement for
[loadbang].
the only difference is, that [initbang] will not make it to the outside
of the patch using [outlet]s.


so you cannot use [initbang] to initialize the parent patch.
darn, bad naming again.
probably [createbang] would be better (esp. if [closebang] is renamed to
[destroybang])
or use [constructorbang] and [destructorbang]


anyhow, whatever the name of the object (even [loadbang really-early]),
th changes to the c-sources will be very similar.


> The initbang help patch is in a pretty sorry state
> right now...  its in SVN doc/pddp if anyone wants to take it on.


probably we should wait whether this evolves before documenting things
to be abandoned.

fgmasdr
IOhannes



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20100823/17d22670/attachment.bin>