[L2Ork-dev] Name clash
jon.w.wilkes at gmail.com
Sat Jul 18 13:12:02 EDT 2020
On Sat, Jul 18, 2020 at 11:14 AM Guillem Bartrina
<guillembartrina at gmail.com> wrote:
> > AFAICT the loader is made up of a bunch of untested, ill-defined
> > For now, I'd say the bug is that a relative path will load
> > 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.
Thanks, I'll have to think about this some more given the behavior you
> > 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?
Seems better to show an error here. Otherwise the user could get caught in a
dialog loop and not understand why it doesn't work.
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
More information about the L2Ork-dev