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