[L2Ork-dev] Name clash

[Jonathan Wilkes]

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
> 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.

Thanks, I'll have to think about this some more given the behavior you
describe here.

>
>  > 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.

-Jonathan

>
>
>
>
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev