Labyrinth: предложения для обсуждения

[gtivansan]

(Галочка там, про что решено.)

Предлагаю внести такие изменение в модуль лабиринта:

- [x] (не делаем) Убрать приставки get и set (Возможно не везде)

Примеры:

labyrinth.unique('Vasya') #Вернёт уникальный объект "Вася", т.к передано только свойство
labyrinth.unique('Vasya', VasyaObject) #Установит ключ, т.к. передано свойство и значение

У всех остальных методов лабиринта нет сеттеров (только геттер) и не может быть по смыслу.

object.parent() # Вернёт родителя
object.parent(newParent) # Установит родителя

и т.д.

У всего кроме флагов так сделать можно.

- [x] (делаем) Полностью запретить __init__ в объектах.

плюсы:

1. Уйдёт огромное кол-во мусорных функций вида smth_safe

2. Не нужно будет париться о том, где писать: в __init__ или в set_settings
   (p.s. к пункту 1: Наверное лучше settings, а не set_settings)

минусы:
Я их не вижу

- [x] (делаем) Убрать or_key аргумент у get_objects (objects в будущем)

Ну он же действительно бесполезный и некрасивый при том.

• (делаем) Ходы:

Сейчас так:
Объект -> строка <- кнопки;
Нужно так:
Объект -> ход -> строка; кнопка -> ход;

• (делаем) Возможно стоит сделать более адекватный поиск по предметам, чем просто перебор.

Хотя бы на уровне, что смотрим только на те объект, lr-тип которых подходящий.
Т.е проходимся только по нужным массивам, а не сразу по всем объектам.

• Добавить ui-классам вместо метода get, методы str и dict

bar.str() # а не str(bar)
button.dict() # а не dict(button)

• (делаем) Декоратор для классов, описывающих уникальные объекты

def add_meta(cls, *args, **kwargs):
    if not 'metadate' in cls.__dict__:
        cls.metadate = {}
    for key in args: cls.metadate[key] = True
    cls.metadate.update(kwargs)
    return cls.metadate

def get_meta(cls):
    if not 'metadate' in cls.__dict__:
        return {}
    return cls.metadate

# декоратор для класса описывающего уникальный предмет
def unique(key):
    """
    key - ключ, который будет установлен
          этому уникальному объекту.
    """
    def unique_decorator(cls):
        old_function = cls.set_settings
        def set_settings(self, *args, **kwargs):
            """
            Новая функция дополнительно будет устанавливать
            указанный уникальный ключ.
            """
            data = old_function(self, *args, **kwargs)
            self.labyrinth.set_unique(self, key)
            return data

        # изменяем функцию в классе.
        cls.set_settings = set_settings
        add_meta(cls, 'unique_object')
        return cls
    return unique_decorator

В самом лабиринте можно добавить проверку того, что объектов уникального класса <= 1

P.S От количества get и set у меня рябит в глазах(

[lounres]

* Убрать приставки get и set

Личное мнение: всё время нужно помнить, что вот эта функция, если ей сказать так, то сделает одно, а если по-другому, то совершенно другое. Так название говорит само за себя, и более-менее понятно, что от неё ждать, а так... нужно всё время помнить, что здесь творится.

* Полностью запретить `__init__` в объектах.

Как я понимаю, у объектов Лабиринта, а не вообще всего. Да, с этим согласен. Может, только если объект имеет конечную природу (т.е. объект, который не будет больше иметь классов-потомков), то не надо это делать.

1. кол-во мусорных функций вида `smth_safe`

Они порождается, как раз, тем, что инициализации нет, поэтому мы не можем гарантировать существование такого атрибута.

* Убрать `or_key` аргумент у `get_objects` (`objects` в будущем)

Подумаю. В какой-то мере согласен.

* Ходы:

Ничего не понял.

* Возможно стоит сделать более адекватный поиск по предметам, чем просто перебор.

Соглашусь. Хотя замечу, что это как-либо полезно только для больших Лабиринтов (с чем-то в чрезмерно большом количестве).

[gtivansan]

Забыл написать из плюсов про то, что код сильно сократится.

А так это идея была мне навеяна прямиком из jquery. Там работает именно так, и я смело могу сказать, что это очень удобно.

[lounres]

* Добавить ui-классам вместо метода `get`, методы `str` и `dict`

Что они будут делать?

[gtivansan]

dict - тоже, что и get. а str - строковое представление всего этого, чтобы отправлять клиенту.

[gtivansan]

Может, только если объект имеет конечную природу

Вроде просто, еси он унаследован от Item Locaiotn Creture Player

[gtivansan]

Они порождается, как раз, тем, что инициализации нет, поэтому мы не можем гарантировать существование такого атрибута

Но это и так ясно. Я и предлагаю решить эту проблему.

[gtivansan]

Хотя замечу, что это как-либо полезно только для больших Лабиринтов

На самом деле это всегда будет бесполезно. Просто потому, что чтобы была видна задержка нужен действительно большой лабиринт + никто задержку не заметит т.к. ждать других игроков все-равно очень долго.

Смысл есть только в эстетике. (Поэтому я написал "возможно")

[gtivansan]

всё время нужно помнить, что вот эта функции

Правильно я понимаю, что основная претензия к синтаксису, а не к читаемости?

Если да, то расскажу, как понять что делает функция, если это не очевидно. (Вдруг мнение изменится)

Если у функции нет аргументов, то это get
Если у функции >=2 аргумента, то это set
Если у функции 1 аргумент, то это get, если мы получаем элемент из множества разных
и set, если элемент уникален, и не требуется указывать какие-либо его свойства.

На самом деле, я сейчас написал, как по функции понять, что она делает.
Вопрос синтаксиса сильно проще. Тебе достаточно передать в функцию все нужные аргументы в нужном порядке и функция сделает то, что ты хочешь. (А список того, что передать, тебе так и так придётся продумывать.)

[gtivansan]

Ничего не понял.

В ходах кратко изложено следующие.
Для кнопок и ходов в данный момент идентификатором является строка. И это плохо т.к. строки бывают одинаковые.
Правильно же будет, если для кнопки идентификатором будет ход. А ход будет содержать своё строковое представление.

[lounres]

Хотя замечу, что это как-либо полезно только для больших Лабиринтов

На самом деле это всегда будет бесполезно. Просто потому, что чтобы была видна задержка нужен действительно большой лабиринт + никто задержку не заметит т.к. ждать других игроков все-равно очень долго.

Смысл есть только в эстетике. (Поэтому я написал "возможно")

Согласен, лучше сделать. Ради эстетики.