[PD] Name conflicts "class overwritten; old one renamed 'x_aliased'

Alexandre Torres Porres porres at gmail.com
Wed Apr 6 00:51:16 CEST 2016


howdy, as a remaining extended 0.42-5 user, I'm just now realizing how
vanilla works when loading externals with the same name as a vanilla object
or some other preloaded library - I have to say it was a surprise to see
that it's different that how extended works, and that it doesn't seem like
a good idea...

Anyway, you see, I got here zexy 2.2.6 (as a library) and cyclone
(individual binaries but also has the nettles library) on vanilla 0.46-7 -
both external libraries have abs~ (which is also a vanilla object) or an
object like [>~] (part of nettles in cyclone). Both zexy and nettles are
loaded via startup.

So funny stuff can happen... like, vanilla's abs~ is overwritten by zexy's
and renamed to abs~_aliased, but if I call cyclone's abs~ specifying its
folder as [cyclone/abs~], it overwrites zexy's abs~ and it is never
possible to call zexy's abs~ ever again...

Ok, in the case of abs~ I think it should be removed from both cyclone and
zexy, because it's not only that they share the same name between each
other and a vanilla object, but they all do the same thing as the internal
object... so it's completely redundanct - but this is another issue. One
way or another, it helps illustrating my point.

So, moving on to the case of [>~], we see from previous discussions that
they need to be loaded as libraries for sanity's sake. But then I can never
specify which [>~] I want - if both are via startup or declare, I can never
be sure or control which one I'm specifying as either >~ or >~_aliased...

The point is: perhaps there could be a better way to force vanilla to load
an internal object?

Or if not a vanilla object, perhaps that could be a way to specify and
object inside one external library or another?

The way things are, it's all just really out of control and I can think of
many scenarios where patches need to be edited when loaded because of
what's going on in that particular machine, such as what patch had been
opened before, etc... I know this probably has been discussed for ages and
many people had already thought about it... I also know I have NO clue on
the technical details and what has already been done, but I would like to
ask and suggest things.

What would make sense to me is that vanilla objects would always prevail
and be called with priority. This is how things were in Extended (and now
pd-l2ork I guess) - externals with the same name as a vanilla objects could
only be called only if explicitly specified.

In the case of cyclone's [line~] it's easy to specify if you wan cyclone's
version or not by specifying the folder [cyclone/line~]

But the problem is when you're using a library, because you seemingly can't
specify a given loaded external library when instantiating an object...
such as [zexy/<~] or [nettles/<~] - and yes, they are different, by the
way, before anyones asks ;)

So, in short, all could be sorted and taken care if:

1- vanilla objects are never overwritten
2- external objects can be specified by a path even if they are loaded as a
library with declare or via the startup (ex: zexy/<~ or nettles/<~)

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160405/2d20b4ca/attachment.html>


More information about the Pd-list mailing list