Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User class #52

Closed
banksJeremy opened this issue May 4, 2014 · 0 comments
Closed

User class #52

banksJeremy opened this issue May 4, 2014 · 0 comments
Assignees

Comments

@banksJeremy
Copy link
Collaborator

As with Message events in #51, we should have deduplicated User instances. These would be referred-to both directly by Events and by Messages.

Messages would have strong references to their owner Users. Users would have a set of weak references to their messages (perhaps a WeakValueSet).

For both this and our other uses, we probably shouldn't expose weak-referencing collections in public attributes, because of the possible issues with iterating over them. We should just have a property or method that returns a strong copy of the collection.

Because we don't make any explicit requests for information about Users and only use what's available, we might only know Users' IDs and names.

Users should probably have a slug property, which returns the name with spaces and special characters removed, as you'd use for an @-mention in chat, and a .message(room, content) method which uses the slug to attempt to message a user in a given room. (Although this will not be successful if they're not active in the room, because we don't have any super-ping functionality or anything, and this could accidentally ping the wrong user just like @-mentions in chat always can.)

@banksJeremy banksJeremy self-assigned this May 6, 2014
@banksJeremy banksJeremy mentioned this issue May 14, 2014
banksJeremy pushed a commit that referenced this issue May 14, 2014
        me = client.get_me()
        sandbox = client.get_room(11540)

        with sandbox.messages() as messages:
            sandbox.send_message("hello worl")

            for message in messages:
                if message.owner is me:
                    assert my_message.content == "hello worl"

ref #65, ref #52, ref #43
banksJeremy pushed a commit that referenced this issue May 15, 2014
They still have no scraping implemented for unknown values.

ref #52, #65
banksJeremy pushed a commit that referenced this issue May 15, 2014
Moves some logic from client to room.

Adds simple docstrings with epydoc annotations to public fields and
methods of Client. Also adds epydoc as a dev dependency, and adds
`make epydocs`.

It probably isn't necessary to add this documentation to our internal
methods, and I won't bother with browser for now, but I think it's
useful to have for our user-friendly interface. (Both for users directly
and through IDEs that recognize the type annotations, like PyCharm CE.)

resolves #52 - let's forget about slugs and message sets for now. We can
reply to messages and a weak set of current messages might be pointless.

ref #65, #43 - event/message iterators/contexts are still outstanding.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant