Hi, I opened an issue on github (see https://github.com/pure-data/pure-data/issues/289), but I thought I'd also post this in the list for a broader attention and possibility of discussion.
So, in cyclone we have a hilbert~ object, that I'm trying to load only as [cyclone/hilbert~], so just "[hilbert~]" would still call the abstraction that resides in "extra".
But that never happens as it seems externals have priority in the search path before the extra folder.
So the only way I can load pd vanilla's hilbert~ is if I don't have cyclone in Pd's path or in [declare], which is bad...
this could be fixed if extra had priority in the search, which I think it'd be common sense, as Pd Vanilla objects actually do have priorities over externals in general.
cheers
On 01/12/2018 03:11 AM, Alexandre Torres Porres wrote:
this could be fixed if extra had priority in the search, which I think it'd be common sense, as Pd Vanilla objects actually do have priorities over externals in general.
no. definitely not. it's "common sense" to allow the user to override vanilla objects.
gfsmdr IOhannes
IOhannes m zmölnig zmoelnig@iem.at writes:
On 01/12/2018 03:11 AM, Alexandre Torres Porres wrote:
this could be fixed if extra had priority in the search, which I think it'd be common sense, as Pd Vanilla objects actually do have priorities over externals in general.
no. definitely not. it's "common sense" to allow the user to override vanilla objects.
I would agree with IOhannes here about the ability to override vanilla objects.
Say for some reason somebody really likes cyclone's hilbert~ and wants to basically ignore the existence of vanilla's hilbert~ so they add cyclone to their path and every time they type in [hilbert~] they want the cyclone one. Under Alex's rules, they keep ending up with vanilla's hilbert and they have no idea why and no good way to get around it, short of deleting vanilla's hilbert~, which I'd argue would be the more destructive and less optimal choice. I think the user should have the power to do what they want. I've at least gotten frustrated using software that overly restricts the user in terms of what they think is safe and proper use case.
Object/method overloading is something not unique to Pd and you always have to think carefully before dumping everything into the main namespace. I don't like typing out extra long wordy names when I don't have to and typing out [cyclone/frameacucm~] would be a pain to do each and every time, but maybe there's a more subtle solution to this. I'm fond of being able to alias imported modules in other languages like the Python numpy example I brought up earlier like "import numpy as np", but again it prob require a complete overhaul of object loading and break everything... I suppose in the meantime we could rename folders or do symbolic links to folders like "ln -s cyclone/ cyc" or something but we can't expect the end user to do that... But I suppose you and I Alex has the same ideas in mind? Half the point of adding paths is to not have to type out the library name each and every time...
Derek
Derek Kwan www.derekxkwan.com
2018-01-12 7:49 GMT-02:00 Derek Kwan derek.x.kwan@gmail.com:
Say for some reason somebody really likes cyclone's hilbert~ and wants to basically ignore the existence of vanilla's hilbert~ so they add cyclone to their path and every time they type in [hilbert~] they want the cyclone one. Under Alex's rules, they keep ending up with vanilla's hilbert and they have no idea why and no good way to get around it, short of deleting vanilla's hilbert~, which I'd argue would be the more destructive and less optimal choice. I think the user should have the power to do what they want. I've at least gotten frustrated using software that overly restricts the user in terms of what they think is safe and proper use case.
I didn't really want to discuss cyclone here, as I think it is not the main focus of this thread at all, but here we go... For cyclone, we actually have many many objects with the same name as vanilla ones, such as [line~], [append], [biquad~], [clip], [clip~], [pow~], [table] and now... perhaps... a new one called [hilbert~].
The thing is we're not overriding any of them automatically and kinda went for a hack to not let this happen on purpose, basically because all of these are not compatible to the vanilla ones and it'd be just also restrictive to users to not let them not override the objects if they don't want to... so say someone doesn't like cyclone's biquad~ or say someone is opening a patch from someone else that uses the vanilla biquad~ one...
For that, we have a very clear documentation in cyclone telling you how to load the object without overriding the vanila ones and it's been like that in cyclone actually since the beginning of times, in the early two thousands... And, well, I just think it is good to keep it that way.
cheers
2018-01-12 6:28 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
you should simply avoid the nameclash.
I agree that's just the best thing to do, but that is not an option for cyclone.
2018-01-12 6:27 GMT-02:00 IOhannes m zmölnig zmoelnig@iem.at:
no. definitely not. it's "common sense" to allow the user to override vanilla objects.
What I'm saying is Pd vanilla objects have priorities. Yes, you can override vanilla objects, but if you have an [osc~] external in a library and you just call [osc~] in Pd, it'll load the vanilla one. So this is my point, that it is common sense and a very well known behaviour that vanilla objects have priority on the search path.
But I just learned that this doesn't happen for objects in the extra folder. Thus I'm considering it an inconsistent behaviour and in conflict with what we normally have in the Pd world.
Now, if Pd forces a priority for vanilla objects ike [osc~], that doesn't really prevent you from being able to override it, as you mentioned. Hence, forcing a priority on the "extra" folder would not prevent this from happening either. So it's not like you cannot do this otherwise it will ruin everything. People will still be able to override it if they want. All that changes is that it'll be consistent with the current behaviour of Vanilla forcing a search priority for vanilla objects.
cheers
On 01/12/2018 03:11 AM, Alexandre Torres Porres wrote:
So, in cyclone we have a hilbert~ object, that I'm trying to load only as [cyclone/hilbert~], so just "[hilbert~]" would still call the abstraction that resides in "extra".
you should simply avoid the nameclash.
fgamdsr IOhannes
-
Alexandre Torres Porres -
Derek Kwan -
IOhannes m zmölnig