Ruby 1.9.2

> не говоря уже о том что в Ruby нельзя чтобы в ~глобальном~области~ — > существовало два класса с одинаковым названием

[в этом случае они ~смешиваются~]

ты так говоришь, будто это плохо.

> Что это? (?_?)

наследование webapp.RequestHandler [класс для обработки http-запросов на стороне сервера] , с прикручиванеим у нему «щётчика» ...

...но не внося новых переменных в получаемый объект (так как они могут конфликтовать с уже существующими, или с тему которые будут там добавленны познее)

нужно перегрузить часть функций внутри наследуемого объекта, но не вводить новых функций-и-переменных внутри класса потомка [включая те переменные который указывают на новые данные, которые требуются для функционирования нового подкласса]..

Эээ… В смысле?

class Moo
	def woof
		'Woof!'
	end
end

class Foo < Moo
	def woof
		'Bark!'
	end
end

puts Foo.new.woof          # Bark!

Или я не очень понимаю о чём ты.

Я про http://www.linux.org.ru/jump-message.jsp?msgid=5246867&cid=5248349

если я хочу специально ~смешать~ — то ничего плохого нет :-)

> Socket_API без IPv6 ... хм.... этож даже не смешно :-/

сокеты это вообще смешно

Ах да,

включая те переменные который указывают на новые данные

Что ты хотел этим сказать?

> Или я не очень понимаю о чём ты.

я про полиморфизм...

тоесть предположим что в твоём примере класс «Moo» имеет ещё кучу методов и его метод «woof» используется НЕ НА ПРЯМУЮ а через какойто метод («woof» это служебная функция.. которая даже не описанна в документации к классу «Moo»)


а мы [после наследования] в классе «Foo» сделам новый метод «woof» , но для своих целей... (просто по названию так он совпала с «woof», но по смыслу там никак не связанно со старой «woof»)


и вот всё.. старые методы от «Moo» уже обращаются к нашей новой «woof».. класс сломан и уже не работает так как должен работать

......а если даже СЕГОДНЯ оно работает как надо...

...то завтра разработчик класса «Moo» введёт СЛУЖЕБНЫЙ метод «woof» . мы [разработчики класса «Foo»] обновим библиотеку классов и у нас всё сломается

> Ах да,

включая те переменные который указывают на новые данные

Что ты хотел этим сказать?

я в том смысле что — если я хочу наследовать чужой класс не для увеличения его ~функциональности~... а всеголишь только для того чтобы предоставить нужный ~интерфейс~

но тем не менее, в будущем классе — будуже какието новые переменные? вот про эти переменные я и говорил :-)

# p.s.: я извеняюсь что немного путаю терминалогию

>мы [разработчики класса «Foo»] обновим библиотеку классов и у нас всё сломается

Знать судьба твоя такая :) На практике сталкиваться не приходилось. Как вариант — префиксы. Ну и вообще,

которая даже не описанна в документации к классу «Moo»)

rdoc генерирует (может по крайней мере) инфу для всех методов, в том числе приватных.

Э... а разве нельзя сделать что-то вроде следующего?

class MainPage
    def initialize
        
        @RequestHandler = webapp.RequestHandler.new

        def @RequestHandler.get
            ...
        end

    end
    ...
end

> Я про http://www.linux.org.ru/jump-message.jsp?msgid=5246867&cid=5248349

в двух словах — здесь описывает способ как в Ruby перейти на объектную модель для классов (а не только для объектов классов)

тоесть чтобы обращение к классу (при создании объектов класса) — было не по его названию.. а по ссылке, которая храниться <гдето-в-какойто-базе>


таким образом можно избежать конфликтов имён при одинаковых названий, но разными смыслами.

конешно — в сообществе Ruby рекомендуют использовать Модули (или как там это правильно называется?) ... и это правильно.... но ~объектная~симантика~ (а не именная семантика) тоже нужна как не крути

>я хочу наследовать чужой класс не для увеличения его ~функциональности~

а всеголишь только для того чтобы предоставить нужный ~интерфейс~

У меня есть сомнения в нужности делать так в руби, но может быть, у меня не настолько прям большой опыт чтобы сказать наверняка :}

>в сообществе Ruby рекомендуют использовать Модули

Не только рекомендуют — все так делают. Так задумано, ничего страшного в них нет.

но ~объектная~симантика~ (а не именная семантика) тоже нужна как не крути

Что именно тебе тут нужно? Обернув в модуль не имеем никаких проблем, удобно, несложно и работает.

> Э... а разве нельзя сделать что-то вроде следующего?

видимо можно... :-)

но внутри метода «def @RequestHandler.get» нужно обращаться:
и к ~self~ внешнего класса
и к ~xself~ внутреннего класса

> Не только рекомендуют — все так делают. Так задумано, ничего страшного в них нет.

ну да да.. разумеется надо! :-) :-) но ещё хотелось ПЛЮС к этому (а не вместо этого) объектную семантику, внутри модуля

> Обернув в модуль не имеем никаких проблем, удобно, несложно и работает.

ну я тут не буду особо спорить :-) :-)

сёравно Ruby и Python — это почти одно и тоже.. только разные конструкции для одних и техже сущностей...

..ну и парачку разных нюансов..

вобщемто в C++ никогда небыло объектнй семантики для Классов и Типов, и для названий функций... и всё было хорошо.... namespace какбы спасает [просто ощущение связанных рук, когда нельзя внутри какойто замкнутой области переименовать парочку типов]


и пишутже на C++ — кучу программ! не жалуются!

> и пишутже на C++ — кучу программ! не жалуются!

Как же ты элегантно перевёл направление в сторону C++ срача...

Создавать внутренний класс, да еще с замыканием и нестандартным названием self?

И этот говнокод вы считаете элегантным?

Серьезных проектов с хорошим покрытием юнит-тестами и долгосрочной поддержкой в большой команде вы никогда не писали, да?

> Руби это не Питон, какой ужас, да.

просто пример из области «всё есть объект» :-)

> Создавать внутренний класс, да еще с замыканием и нестандартным названием self?

еслибы СЛОВО self было СТАНДРТНЫМ для каждого метода...

...то ответтье мне тода на вопрос: «зачем вообще писать это слово, если оно такое уж прям стандартное? вставлось бы автоматически?»

так нет уж.. если писать нада вручную.. значит self это не стандарт

>просто пример из области «всё есть объект» :-)

Ну, «всё» здесь относительно. Блок сам по себе не объект, например, методы там и т.д.

>еслибы СЛОВО self было СТАНДРТНЫМ для каждого метода...

У Гвидо написано, что это устная договоренность, но ее рекомендуется придерживаться.

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

Выше уже писали. В питоне ООП прикручено сбоку и подперто костылями. Вот self не вставляется автоматически и вообще явный аргумент.

> если писать нада вручную.. значит self это не стандарт

Ты наркоман что ли? PEP8-то прочти.

PEP8

Always use 'self' for the first argument to instance methods.

А еще лучше не пиши на питоне больше. Не надо.

я тоже подедрживаю — что нада писать везде self (и также щитают все текстовые редакторы, выделяя self как встроенную_функцию)

....но в случаях когда нада сделать micro-class для замыкания (внутри метода какогото большого класса) — использование self (а не xself или subself) — может только запутать код программы

думаю что лучше делать так как это меньше относительно запутывания :-)

> В питоне ООП прикручено сбоку и подперто костылями. Вот self не вставляется автоматически и вообще явный аргумент.

а по какой причине не исправили в Python-3 ? сёравноже сломали совместимость?

> Always use 'self' for the first argument to instance methods.

в C/C++ тоже запрещают использовать goto... однако в ряде [очень малочисленных] исключений — использование goto (например при выходе из циклов) — goto очень укорачивает [и не запутывает] код

ясное дело что в ОБЫЧНЫХ случаях — нада использовать self.....

...но я то затронул исключительую ситуацию :-/ :-/ :-/ :-/

> А еще лучше не пиши на питоне больше. Не надо.

не не.. не волнуйтесь :-) .. в общестыенне репозитарии мои говнокоды я не предлагаю класть :-D

> Новая библиотека psych, являющаяся обёрткой libyaml, которую можно использовать вместо syck.

использовать вместо syck.

Видать с девушками у них проблемы...

> думаю что лучше делать так как это меньше относительно запутывания

Т.е. ты реально настолько глуп и считаешь, что нестандартный быдло-подход с созданием новых классов в рантайме на каждый чих намного лучше общеизвестного dependency injection? Который всем знаком, всеми используется, много выгоднее и много легче поддерживается.

а по какой причине не исправили в Python-3 ? сёравноже сломали совместимость?

Гвидо сразу зассал и заявил, что не будет из питона3 делать чистый язык, исправляя ошибки молодости. Все что они сделали - выкинули костыли, которые сохранялись для совместимости еще с питона 1.

Поломанной совместимости на 1 страничку не наберется. Единственное серьезное изменение - строгое деление на юникод и байты. Большую часть всего остального уже портировали обратно в 2.{6,7}.

в C/C++ тоже запрещают использовать goto

Кто его запрещает-то?

но я то затронул исключительую ситуацию

Исключительность твоей ситуации в том, что ты не знаешь design patterns и городишь собственный быдло-код для решения стандартных задач.

>> В питоне ООП прикручено сбоку и подперто костылями. Вот self не вставляется автоматически и вообще явный аргумент.

а по какой причине не исправили в Python-3 ?

Потому что это не ошибка.

> Джентльмены, а что круче: Перл, Руби или Питон?

tcl

> class Foo < Moo

Что бы это могло значить? Класс Foo меньше, чем класс Moo? Или это ещё одна неочевидная перегрузка лексемы? Если так, то у D в этом плане появился конкурент. ;)

>> Джентльмены, а что круче: Перл, Руби или Питон?

tcl

Походу, место в топе крутизны обратно пропорционально месту в топе практической используемости.

> Т.е. ты реально настолько глуп и считаешь, что нестандартный быдло-подход с созданием новых классов в рантайме на каждый чих намного лучше общеизвестного dependency injection?

да я настолько глуп! так как,.... просто показал пример где self имеет смысл называть подругому (не self)...

...а в это время ты можешь нагораживать какие хочешь внедрения зависимостей и описывать классы НЕ в рантайме... никто тебе это не запрещает

но знай что от перемены слагаемых сумма не меняется: просто теже самые процессы которые происходили во время {описания класса} — теперь будут происходить во время {инициализации объекта} [и опятьже будет затраченно столькоже времени выполнения, в ращщёте на каждый чих]


а если уж ты через бохзнает какие ещё шалоны проектирования нагородишь и ЕЩЁ кучу вспомогательных классов — то тоже пожаласта — можешь и так поступить...... но я сразу сказал что рассматриваю случаи когда внутренний класс — МАЛЕНЬКИЙ ... МИКРО КЛАСС... от которого всё что нада так это только чужой {интерфейс} . а не какието там огромные внутренний классы :-)

Сян_Петро.xbm

> Класс Foo меньше, чем класс Moo?

Наследование (foo от moo). Логичнее, конечно, было бы стрелку сделать, но Matz, видать, думал по-другому.
P.S. И таки да, класс Foo меньше, чем Moo :)

>Логичнее, конечно, было бы стрелку сделать

Стрелка вправо уже есть. Ещё влево нехватало %)

Не залезая в исходники можно предположить 64 бита для хранения значения со всеми вытекающими

да я настолько глуп!

Это был риторический вопрос. Я не сомневался.

где self имеет смысл называть подругому (не self)

Даже в твоем примере в этом нет смысла.

и опятьже будет затраченно столькоже времени выполнения, в ращщёте на каждый чих

В твоем примере при каждом вызове функции будет создан новый класс, создано замыкание, и новый экземпляр этого класса. Но я не ожидаю, что ты поймешь, что это медленнее, сложнее и требует больше памяти.

Еще мне бы очень хотелось посмотреть как ты покроешь всю эту конструкцию юнит-тестами.

нагородишь и ЕЩЁ кучу вспомогательных классов

Да я уже понял, что design patterns ты не знаешь, над крупными проектами не работал. Но хотя бы ради приличия ознакомься с матчастью, а? Например:

class MyTest: 
    def __init__(self, name): 
        self.name = name 
     
    def make_other(self, name):
        return MyOther(self, name)

class MyOther: 
    def __init__(self, other_class, name):
        self.other_class = other_class
        self.name = name 
             
    def get_name(self): 
        return '%s/%s' % (self.name, self.other_class.name)

>Походу, место в топе крутизны обратно пропорционально месту в топе практической используемости.

Походу, место в топе крутизны обратно пропорционально кубу места в топе практической используемости.

obvious fix :)

> Стрелка вправо уже есть. Ещё влево нехватало %)

Добро пожаловать к нам в ерланг :)

http://en.wikibooks.org/wiki/Erlang_Programming/List_Comprehensions

Ну а стрелка вправо используется для объявления функции.

> Но я не ожидаю, что ты поймешь, что это медленнее, сложнее и требует больше памяти.

в твоём примере ты создал функцию __init__ — которая взяла на себя обязанности, которое раньше были возложенны на процесс создания класса

наверно тебе не стоит обзяснять что __init__ выполняется кажый раз при создании экземпляра?

вообще — лучше приведи пример для:
http://www.linux.org.ru/jump-message.jsp?msgid=5246867&cid=5248371

(не над чтоб прям компилировался без ошибок.. хотяб просто примерно)

Уж лучше вы к нам (^ ^)

> Уж лучше вы к нам (^ ^)

(^ ^) Это какой-то оператор из руби? :)

Пока ещё нет, просто смайлик :)

на костылях прикрутили ООП это в каком смысле?

например:

>>> class TObject(object):
...     pass

...а вот и не правда:

>>> o = object()
>>> o.prop = 'test'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'object' object has no attribute 'prop'

>>> t = TObject()
>>> t.prop = 'test'
>>>

> в инстанс наследника можно динамически добавлять атрибуты, а в инстанс родителя - нельзя. с точки зрения ООП - полный бред.

Скорее на бред похожи твои слова. В экземпляры класса object нельзя добавлять атрибуты, и что с того?

> Скорее на бред похожи твои слова. В экземпляры класса object нельзя добавлять атрибуты, и что с того?

так мы про ООП или про костыли? запись `class TObject(object): pass` как бы намекает на то, что к object нового поведения не добавляется.