[Fwd: Re: managed lists?]

[Jorgen Bodde]

@ Larry,

As much as I like to follow the idiom that Python has, I do not see
the usefulness of making an add function that checks the interface
that other objects might need. Besides the fact it is a bit overhead
and not to mention performance draining, in an application that I
develop myself, without plugin architecture (not yet) etc, it is a bit
much to do that.

I agree with the writing C in Python, it is all I know, because that
is the language I started with. This is my first big project and most
certainly when evaluating this when it is finished I will come to the
conclusion it was all for nothing ;-)

I will change to extend() and maybe drop the type safety, but I do
wish to keep the list functionality as I find it more logical to write

song.categories.append()

Then creating a method in song called AddCategory() and kind of
duplicating the list functionality there.

Thank you for the guide lines and the nice comments! They are really helpful.

@ Bruno,

> list. The right solution IMHO is to *not* expose these lists as part of
> the interface - after all, the fact that tabs and tunes are stored in
> lists is an implementation detail -, and to add the necessary API to the
> Song object - ie : Song.add_tune, Song.add_tab, Song.iter_tunes,
> Song.iter_tabs, etc. Then you just have to add some assert statements in
> the add_XXX methods so you'll be warned at the right time when some part

This is how I did it before, I created Song.AddTab, Song.DeleteTab,
then there was a category class which also needed adding, deleting,
clearing, and soon my whole Song object was filled with relational
methods which were basically a copy of the list, with a check on the
presence of the class in the list.

Then I realized, a managed list with self-check capability solves this
because I do not like to duplicate code, but now that I think of it,
the type check might be a bit too much. Like said, the list solution
you described and the solution I use, are basically the same, I
encapsulated a list [] in a class, with some extra methods to warn the
'owner' of the list that something is changed.

> Oh, yes, while we're at it, and in case you don't know yet: the Python
> idiom for implementation attributes (including methods - remember,
> everything is an object) is to prefix them with a single underscore.

Ok, but why is that? I do know semi-private symbols can be realised
using two underscores, and if I wish to hide a list / index / etc so
it cannot accidentally changed, would I not use double underscores?

Thanks for your extensive help!
- Jorgen