Community naming convention. about dispersy HOT 9 CLOSED

Makes sense, however if we changing this it might be a good idea to see if we can move some methods from dispersy.py to community.py.

For instance, creating an introduction request is clearly something a community is responsible for, not dispersy.py.
Same goes for receiving them etc.

from dispersy.

I agree with you, +1 for moving all message related methods from dispersy.py to community.py.

I'd still like your guy's opinion on the naming convention.

from dispersy.

I don't mind the create stuff, i guess it makes sense to have such a keyword for methods which create messages.
The dispersy prefix I dislike, i'd rather use the first option for those instead.

from dispersy.

I agree with @NielsZeilemaker

from dispersy.

I agree with using the first option.

Historically the naming convention for create, check, on, and undo methods was: create_MESSAGENAME, check_MESSAGENAME, etc. given that the Dispersy messages include the word 'dispersy' in their name, all these methods become: create_dispersy_aaa, check_dispersy_aaa, etc. When implemented in disprsy.py I choose to remove 'dispersy' from these method names, I'm not convinced we should do the same when we move this into community.py?

I do agree that having the word 'dispersy' everywhere isn't useful. Should we, to make things consistent, rename the messages themselves? I.e. 'dispersy-introduction-requesy' --> 'introduction-request'? This way we can keep the naming convention while keeping reasonable methods names.

from dispersy.

+1

from dispersy.

Any progress on this? I think it would improve the readability of Dispersy a lot if we could move some methods from dispersy.py to community.py.

from dispersy.

I've pointed Johan to this thread last week when discussing its merits. I'm waiting for him to say yay or nay on the time investment.

from dispersy.

Done, most of the dispersy prefixes are gone and all messages have been moved to community.py

from dispersy.