[PD-dev] gem vs. mrpeach strings?

[Martin Peach]

IOhannes m zmoelnig wrote:
> Martin Peach wrote:
>   
>> IOhannes m zmoelnig wrote:
>>     
>>> the [text3d]... objects expect a "string" message with pdstrings
>>> (according to moocows stuff).
>>>       
>> OK, so the message [string( is being interpreted by pd as a selector for 
>> A_STRING instead of just a message "string", because "string" has become a 
>> reserved word.
>>     
>
> correct.
>
> my proposal is therefore to entirely skip reserved words when 
> introducing new types and solely rely on the atom-type (A_BLOB), rather 
> than the list selector.
>
>   
Fair enough, but that would mean changing the pd API, for instance the 
class_addmethod function, which wants a selector. Pd seems to use the 
type A_BLOB in some places and the selector s_blob in others, I'm not 
sure if it could be made to use only the type without breaking all the 
currently existing externals.

> do you have any strong reason why you need to reserve a selector when 
> introducing a new atom-type?
> (apart from: "that was the way it seemed to be done")
>   

That's right. I basically copied the way it was done for floats and 
lists. I tried not using a selector but things didn't work properly, 
like class_addmethod. If you can see how it could be made to work 
without the selector, please let us know.

>   
>>> your string-patch adds a special message "string" for your strings.
>>> i think that is where the problem comes in: A_GIMME != A_STRING
>>>
>>>       
>> The latest version of the patch in cvs calls it A_BLOB instead of A_STRING. 
>> Does this resolve the issue? Or will it cause [blob( messages to go wrong?
>>     
>
> the problem is not with A_BLOB vs A_STRING, but with use of selectors. 
> see above.
True, I forgot to mention that I also changed the "string" selector to "blob".

Martin