[L2Ork-dev] Name clash

[Guillem Bartrina]

 > AFAICT the loader is made up of a bunch of untested, ill-defined 
branches.

 > For now, I'd say the bug is that a relative path will load 
abstractions/external
 > binaries that have a nameclash with a built-in.

Imagine you have the following file hierarchy:

/

- home/

             - main.pd

             - subdir/

                           - abs.pd


Typing "subdir/abs" or "/home/subdir/abs" into an object box will 
trigger two different behaviours.

In the first case only "subdir/abs" is added to the pd_objectmaker 
method list, while in the second case both "abs" and "/home/subdir/abs" 
are added. At first, this is a confusing behaviour for the user.

Secondly, we have the problem with the built-in special methods (float, 
bang, list, ..) that has their own and separately treatment on the 
codebase. Maybe this could be avoided by checking if 'addmethod' is 
being used on pd_objectmaker and, in that case, handle it different for 
these special methods.

 > Is there a way to keep the loader as-is, but in your feature prevent 
the user
 > from saving the abstraction with a built-in name? That may be the most
 > expedient course of action.

Is a general problem involving abstractions, that by chance affects the 
feature I'm implementing. But yes, I'm almost sure there is a way keep 
the leader as-is and prevent the user from saving the abstraction with a 
built-in name.

In the mentioned case, should it show an error and abort the process? Or 
should it reopen the file chooser dialog until a valid name is entered?