Здравствуйте, c-smile, Вы писали:
CS>Оно нормальное в любом языке этой группы: PHP, Ruby, LUA и пр. CS>В том смысле что все OOP парадигмы можно реализовать в них с примерно одинаковым уровнем рвотных позывов на сроку текста.
Lua совсем не вписывается со своим табличным ООП.
В PHP тоже вроде не фонтан.
В руби и питоне да вполне хороший, помощнее в некоторых аспектах чем ООП в C++/C#/Java.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, c-smile, Вы писали:
CS>>Оно нормальное в любом языке этой группы: PHP, Ruby, LUA и пр. CS>>В том смысле что все OOP парадигмы можно реализовать в них с примерно одинаковым уровнем рвотных позывов на сроку текста.
FR>Lua совсем не вписывается со своим табличным ООП.
Таблицы в Lua как механизм идентичен prototype based inheritance исповедуемых Python и Ruby.
Разница лишь в количестве пальцев требуемых для получения результата.
FR>В PHP тоже вроде не фонтан.
То же самое. +/- запах разве что.
FR>В руби и питоне да вполне хороший, помощнее в некоторых аспектах чем ООП в C++/C#/Java.
Руби, Питон и JS кстати это близнецы братья по внутреннему устройству.
Т.е. динамический OOP во всем своем блеске и нищете. Т.е. руками можно соорудить например любой тип наследования.
Вопрос состоит лишь в физиологических предпочтениях практикующего.
Технически например методы классов в Python могут обходиться без обязательного self в списке параметров. Это явно
наследие прошлого.
На самом деле это проблема — достижение некоего разумного баланса между OOP и функциональным подходом.
Я имею ввиду нотацию в основном так как внутри что Python что JS одно и то же.
Понятно что чистая OOPность и чистая функциональщина как все сугубо абстрактное имеют мало шансов по жизни.
В реалии работает то что находится в золотой середине.
Здравствуйте, artem_korneev, Вы писали:
_>По-моему, лучше всё-таки освоиться с питоном. Язык очень хороший, несмотря на некоторые синтаксические неудобства. Для разработки на питоне доступны неплохие IDE, питон встроен в качестве скриптового языка во многие приложения (OOo, GIMP и т.д.), плюс помимо "мейнстрима", доступны несколько сторонних реализаций питона — CPython, IronPython, есть "portable"-версии, не требующие установки в системе, Google вот ещё обещает что проект unladen-swallow позволит ускорить питон в разы.. хотя сомнительно. Но всё равно хуже не будет. Для питона имеется инструментарий для получения бинарников, не требующих установленного питона (py2exe). Есть биндинги к большинству GUI библиотек (Qt, wxwidgets, gtk). Вроде как на питоне можно писать под симбиан и какие-то смартфонооси.. но я не пробовал.
По-моему, лучше всё-таки освоиться с Руби. Язык очень хороший, без синтаксических неудобств. Для разработки на руби доступны неплохие IDE, плюс помимо "мейнстрима", доступны несколько сторонних реализаций Руби — jruby, IronRuby, Ruby Enterprise Edition, Rubinius, MacRuby, есть "portable"-версии, не требующие установки в системе, кто-то вот еще обещает что проект MagLev позволит ускорить Руби в разы.. Для Руби имеется инструментарий для получения бинарников, не требующих установленного Руби (orca, раньше еще был rubyscript2exe). Есть биндинги к большинству GUI библиотек (Qt, wxwidgets, Tk, Fox, GTK2, Cocoa). На Руби можно писать под симбиан и какие-то смартфонооси (WM, iPhone, Android) — см. Rhodes.
Здравствуйте, c-smile, Вы писали:
CS>Таблицы в Lua как механизм идентичен prototype based inheritance исповедуемых Python и Ruby.
Питон и Руби не исповедуют прототипное наследование. Вообще ООП в них склонирован со Smalltalk и
сильно отличается от прототипных прародитель которых Self хоть и потомок того же Smalltalk но ОО в
нем кардинально переделано.
Другое дело реализация всех этих вещей, да очень сильно похожа во всех динамических языках как раз
в виде таблиц. Но если так рассуждать то и в Си как и Lua есть ООП на структурах и он идентичен
тому что в C++ ведь в ассемблер они одинаково компилируются.
CS>Разница лишь в количестве пальцев требуемых для получения результата.
Угу у Си с С++ также.
FR>>В PHP тоже вроде не фонтан.
CS>То же самое. +/- запах разве что.
Угу навоз и фиалки при правильной концентрации хим. веществ пахнут практически одинаково
FR>>В руби и питоне да вполне хороший, помощнее в некоторых аспектах чем ООП в C++/C#/Java.
CS>Руби, Питон и JS кстати это близнецы братья по внутреннему устройству.
Если чуть подняться от таблиц методов уже проявляются большие различия.
CS>Т.е. динамический OOP во всем своем блеске и нищете. Т.е. руками можно соорудить например любой тип наследования. CS>Вопрос состоит лишь в физиологических предпочтениях практикующего.
Ну это просто особенности динамики.
CS>Технически например методы классов в Python могут обходиться без обязательного self в списке параметров. Это явно CS>наследие прошлого.
Так старенький уже питон там есть что найти археологам
CS>На самом деле это проблема — достижение некоего разумного баланса между OOP и функциональным подходом. CS>Я имею ввиду нотацию в основном так как внутри что Python что JS одно и то же.
Тут не понял причем функциональщина.
Я вижу в питоне и JS два разных типа ООП — классический Smaltallk против прототипного. А ФЯ возможности это
отдельный критерий.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, c-smile, Вы писали:
CS>>Таблицы в Lua как механизм идентичен prototype based inheritance исповедуемых Python и Ruby.
FR>Питон и Руби не исповедуют прототипное наследование. Вообще ООП в них склонирован со Smalltalk и FR>сильно отличается от прототипных прародитель которых Self хоть и потомок того же Smalltalk но ОО в FR>нем кардинально переделано. FR>Другое дело реализация всех этих вещей, да очень сильно похожа во всех динамических языках как раз FR>в виде таблиц. Но если так рассуждать то и в Си как и Lua есть ООП на структурах и он идентичен FR>тому что в C++ ведь в ассемблер они одинаково компилируются.
Я не вижу разницы (принципиальной во всяком случае) между Python:
proto = obj.__bases__
и JavaScript
var proto = obj.obj.__proto__;
Сущность одна и та же, только имена разные.
То же самое на запись. В runtime у объекта можно изменить класс. Просто в JS класс стыдливо называется prototype ибо у автора креативность кончилась к тому моменту ...
В C++ кстати тоже у объекта можно сменить класс в runtime, причем штатными методами.
FR>>>В руби и питоне да вполне хороший, помощнее в некоторых аспектах чем ООП в C++/C#/Java.
CS>>Руби, Питон и JS кстати это близнецы братья по внутреннему устройству. FR>Если чуть подняться от таблиц методов уже проявляются большие различия.
Ну это нюансы, согласись. Big picture всё та же. +/- пара кунштюков в runtime.
CS>>На самом деле это проблема — достижение некоего разумного баланса между OOP и функциональным подходом. CS>>Я имею ввиду нотацию в основном так как внутри что Python что JS одно и то же.
FR>Тут не понял причем функциональщина.
Ну как минимум first class functions. Ну понятно что это далеко не всё функциональное программирование. Тем не менее.
FR>Я вижу в питоне и JS два разных типа ООП — классический Smaltallk против прототипного. А ФЯ возможности это FR>отдельный критерий.
Да нет никакого особого отличия в Smaltallk inheritance от JS inheritance. Так — детали, деталюшки.
If you look back at Smalltalk, since you can open a class and add methods, this is effectively the same as what you can do in Javascript.
CS>То же самое на запись. В runtime у объекта можно изменить класс. Просто в JS класс стыдливо называется prototype ибо у автора креативность кончилась к тому моменту ...
Понятно что динамика все сильно размывает, но база-то все равно разная.
CS>В C++ кстати тоже у объекта можно сменить класс в runtime, причем штатными методами.
Покажешь?
CS>Ну это нюансы, согласись. Big picture всё та же. +/- пара кунштюков в runtime.
Не соглашусь, метаклассы по моему мощнее на практике, хотя в теории наоборот.
Да и работают метаклассы в том же питоне скорее в аналоге compilе-time в момент загрузки модуля.
FR>>Тут не понял причем функциональщина.
CS>Ну как минимум first class functions. Ну понятно что это далеко не всё функциональное программирование. Тем не менее.
Это понятно, не понятно как это относится к теме разговора
FR>>Я вижу в питоне и JS два разных типа ООП — классический Smaltallk против прототипного. А ФЯ возможности это FR>>отдельный критерий.
CS>Да нет никакого особого отличия в Smaltallk inheritance от JS inheritance. Так — детали, деталюшки. CS>
CS>If you look back at Smalltalk, since you can open a class and add methods, this is effectively the same as what you can do in Javascript.
Здравствуйте, FR, Вы писали:
CS>>В C++ кстати тоже у объекта можно сменить класс в runtime, причем штатными методами.
FR>Покажешь?
Да легко:
#include <new>
#include"assert.h"class A
{
int t;
public:
A(int n):t(n) {}
virtual void show() { printf("as A:%d\n",t); }
};
class B
{
int t;
virtual void show() { printf("as B:%d\n",t); }
};
// turn_to<B>(A* obj) changes class of the object
// that means it just replaces VTBL of the object to VTBL of another class:template <typename TO_T, typename FROM_T>
inline void turn_to(FROM_T* p)
{
assert( sizeof(FROM_T) == sizeof(TO_T));
::new(p) TO_T();
}
int main(int argc, char* argv[])
{
A* hameleon = new A(123);
hameleon->show();
turn_to<B>(hameleon);
hameleon->show();
return 0;
}
FR>Есть различия и огромные, ты в метаклассах питоновских поковыряйся думаю много открытий сделаешь
Все зависит от уровня абстракции. Я в свое время (pre-tiscript) проводил исследование для себя и как-то они все уложились в одну категорию.
Фичи одни и те же. Детали само собой разные.
Здравствуйте, c-smile, Вы писали:
CS>>>В C++ кстати тоже у объекта можно сменить класс в runtime, причем штатными методами.
FR>>Покажешь?
CS>Да легко:
Хак чистейший, полагается на общепринятую реализацию виртуальных методов.
Ну и смены типов нет, просто пересоздание объекта в той же области памяти где был старый.
FR>>Есть различия и огромные, ты в метаклассах питоновских поковыряйся думаю много открытий сделаешь
CS>Все зависит от уровня абстракции. Я в свое время (pre-tiscript) проводил исследование для себя и как-то они все уложились в одну категорию. CS>Фичи одни и те же. Детали само собой разные.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, artem_korneev, Вы писали:
_>>По-моему, лучше всё-таки освоиться с питоном. Язык очень хороший, несмотря на некоторые синтаксические неудобства. Для разработки на питоне доступны неплохие IDE, питон встроен в качестве скриптового языка во многие приложения (OOo, GIMP и т.д.), плюс помимо "мейнстрима", доступны несколько сторонних реализаций питона — CPython, IronPython, есть "portable"-версии, не требующие установки в системе, Google вот ещё обещает что проект unladen-swallow позволит ускорить питон в разы.. хотя сомнительно. Но всё равно хуже не будет. Для питона имеется инструментарий для получения бинарников, не требующих установленного питона (py2exe). Есть биндинги к большинству GUI библиотек (Qt, wxwidgets, gtk). Вроде как на питоне можно писать под симбиан и какие-то смартфонооси.. но я не пробовал.
DM>По-моему, лучше всё-таки освоиться с Руби. Язык очень хороший, без синтаксических неудобств. Для разработки на руби доступны неплохие IDE, плюс помимо "мейнстрима", доступны несколько сторонних реализаций Руби — jruby, IronRuby, Ruby Enterprise Edition, Rubinius, MacRuby, есть "portable"-версии, не требующие установки в системе, кто-то вот еще обещает что проект MagLev позволит ускорить Руби в разы.. Для Руби имеется инструментарий для получения бинарников, не требующих установленного Руби (orca, раньше еще был rubyscript2exe). Есть биндинги к большинству GUI библиотек (Qt, wxwidgets, Tk, Fox, GTK2, Cocoa). На Руби можно писать под симбиан и какие-то смартфонооси (WM, iPhone, Android) — см. Rhodes.
DM>
Итак, вы хотите начать учить Руби. Ну, хватайте себе копию и — вперед. Только вот, какой Руби... 1.8.6, 1.8.7, 1.9.1 или 1.9.2... Есть еще JRuby, Ruby Enterprise Edition, Rubinius... И все они немного разные
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, c-smile, Вы писали:
CS>>>>В C++ кстати тоже у объекта можно сменить класс в runtime, причем штатными методами.
FR>>>Покажешь?
CS>>Да легко:
FR>Хак чистейший, полагается на общепринятую реализацию виртуальных методов.
Умммм... где конкретно-то хак? Нет там никакого хака.
"общепринятую реализацию виртуальных методов" — это то на чем основаны все имплементации COM и Cobra.
Во вском случае COM имеет дуальные бинарно совместимые имплементации в C++ и C.
Вот на этом факте я и основываюсь.
FR>Ну и смены типов нет, просто пересоздание объекта в той же области памяти где был старый.
Смена класса (замена VTBL) есть. Пересоздание объекта — нет. Я же специально значение member variable вывел — оно не изменилось.
Метод не без ограничений, но вполне себе работоспособный в рамках области применения.
FR>>>Есть различия и огромные, ты в метаклассах питоновских поковыряйся думаю много открытий сделаешь
CS>>Все зависит от уровня абстракции. Я в свое время (pre-tiscript) проводил исследование для себя и как-то они все уложились в одну категорию. CS>>Фичи одни и те же. Детали само собой разные.
FR>Похоже ты смотрел слишком издалека.
Ты говоришь : вишня и черешня это небо и земля. Я говорю вишня и черешня это косточковые.
И мы оба по своему правы. Но используем разные таксономии.
Здравствуйте, c-smile, Вы писали:
FR>>Хак чистейший, полагается на общепринятую реализацию виртуальных методов.
CS>Умммм... где конкретно-то хак? Нет там никакого хака.
Да там по стандарту наверняка UB.
CS>"общепринятую реализацию виртуальных методов" — это то на чем основаны все имплементации COM и Cobra. CS>Во вском случае COM имеет дуальные бинарно совместимые имплементации в C++ и C. CS>Вот на этом факте я и основываюсь.
Угу завязка на реализацию. Даже под винды можно на какой-нибудь gcc который на com кладет налететь.
FR>>Ну и смены типов нет, просто пересоздание объекта в той же области памяти где был старый.
CS>Смена класса (замена VTBL) есть. Пересоздание объекта — нет. Я же специально значение member variable вывел — оно не изменилось.
Ну добавь B() : t(456) {} и будет тебе изменение.
Тут чистое пересоздание с помощью placement new и больше ничего.
CS>Метод не без ограничений, но вполне себе работоспособный в рамках области применения.
По моему стремновато.
FR>>Похоже ты смотрел слишком издалека.
CS>Ты говоришь : вишня и черешня это небо и земля. Я говорю вишня и черешня это косточковые. CS>И мы оба по своему правы. Но используем разные таксономии.
Здравствуйте, Mamut, Вы писали:
M>Итак, вы хотите начать учить Руби. Ну, хватайте себе копию и — вперед. Только вот, какой Руби... 1.8.6, 1.8.7, 1.9.1 или 1.9.2... Есть еще JRuby, Ruby Enterprise Edition, Rubinius... И все они немного разные
По сути, в языке есть только две немного отличающиеся версии — 1.8 и 1.9. Все сторонние реализации совместимы с одной из них или являются форком одной из них.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, c-smile, Вы писали:
FR>>>Хак чистейший, полагается на общепринятую реализацию виртуальных методов.
CS>>Умммм... где конкретно-то хак? Нет там никакого хака.
FR>Да там по стандарту наверняка UB.
Так точно или это ты так предполагаешь?
CS>>"общепринятую реализацию виртуальных методов" — это то на чем основаны все имплементации COM и Cobra. CS>>Во вском случае COM имеет дуальные бинарно совместимые имплементации в C++ и C. CS>>Вот на этом факте я и основываюсь.
FR>Угу завязка на реализацию. Даже под винды можно на какой-нибудь gcc который на com кладет налететь.
"gcc который на com кладет" это тебя нагло обманули.
На GCC очень даже хорошо можно с COM работать. И имплементировать оные IUnknown derived интерфейсы. grep на IUnknown в конце концов.
FR>>>Ну и смены типов нет, просто пересоздание объекта в той же области памяти где был старый.
CS>>Смена класса (замена VTBL) есть. Пересоздание объекта — нет. Я же специально значение member variable вывел — оно не изменилось.
FR>Ну добавь B() : t(456) {} и будет тебе изменение.
А ты не добавляй. И не будет тебе изменение. Причем по спецификации.
FR>Тут чистое пересоздание с помощью placement new и больше ничего.
Термин "пересоздание" мне не известен. Есть "конструирование по месту" которое четко специфицировано что делает в C++.
Если members не инициализируются явно то их значение не меняется. И это ж-ж-ж неспроста.
А "пересоздание" это твоя ментальная модель такая. Советую её пересмотреть.
CS>>Метод не без ограничений, но вполне себе работоспособный в рамках области применения.
FR>По моему стремновато.
Глупые родители говорят своим чадам что острый ножик это стремно.
Умные объясняют что острый ножик это хорошо, с ним можно смастерить много полезных вещей. Но неаккуратное использование может приводить к нежелательным последствиям.
Вот мы и выяснили откуда блондинки происходят.
FR>>>Похоже ты смотрел слишком издалека.
CS>>Ты говоришь : вишня и черешня это небо и земля. Я говорю вишня и черешня это косточковые. CS>>И мы оба по своему правы. Но используем разные таксономии.
FR>Угу, только ты говоришь все фрукты одинаковы
Здравствуйте, c-smile, Вы писали:
FR>>Да там по стандарту наверняка UB.
CS>Так точно или это ты так предполагаешь?
Предполагаю конечно. Я не знаток стандарта.
Но даже я вижу что для объекта A не вызываются деструкторы.
И если в классах есть не POD члены:
#include <new>
#include <stdio.h>
#include"assert.h"#include"string"class A
{
std::string t;
public:
A(const char *n):t(n) {}
virtual void show() { printf("as A:%s\n", t.c_str()); }
};
class B
{
std::string t;
virtual void show() { printf("as B:%s\n",t.c_str()); }
};
// turn_to<B>(A* obj) changes class of the object
// that means it just replaces VTBL of the object to VTBL of another class:template <typename TO_T, typename FROM_T>
inline void turn_to(FROM_T* p)
{
assert( sizeof(FROM_T) == sizeof(TO_T));
::new(p) TO_T();
}
int main(int argc, char* argv[])
{
A* hameleon = new A("123");
hameleon->show();
turn_to<B>(hameleon);
hameleon->show();
return 0;
}
то все не так работает как тебе хочется.
FR>>Угу завязка на реализацию. Даже под винды можно на какой-нибудь gcc который на com кладет налететь.
CS>"gcc который на com кладет" это тебя нагло обманули. CS>На GCC очень даже хорошо можно с COM работать. И имплементировать оные IUnknown derived интерфейсы. grep на IUnknown в конце концов.
С gcc с com я работал еще с версией 2.x вполне возможно сейчас классы там и совместимы с com моделью, тогда нам пришлось
писать сишные обертки для com иначе виртуальная таблица не стыковалась.
FR>>Ну добавь B() : t(456) {} и будет тебе изменение.
CS>А ты не добавляй. И не будет тебе изменение. Причем по спецификации.
Угу, а кто-то после меня добавит и будет глюк и тоже по спецификации.
FR>>Тут чистое пересоздание с помощью placement new и больше ничего.
CS>Термин "пересоздание" мне не известен. Есть "конструирование по месту" которое четко специфицировано что делает в C++. CS>Если members не инициализируются явно то их значение не меняется. И это ж-ж-ж неспроста.
Меняется если эти члены не POD смотри код выше.
FR>>По моему стремновато.
CS>Глупые родители говорят своим чадам что острый ножик это стремно. CS>Умные объясняют что острый ножик это хорошо, с ним можно смастерить много полезных вещей. Но неаккуратное использование может приводить к нежелательным последствиям.
Угу а до альфы центавра ровно 4.36 световых лет.
FR>>Угу, только ты говоришь все фрукты одинаковы
CS>Это не я так говорю. Это ты так читаешь.
On 11/08/10 21:57, c-smile wrote: > FR>Ну добавь B() : t(456) {} и будет тебе изменение. > А ты не добавляй. И не будет тебе изменение. Причем по спецификации.
По спецификации неинициализированные переменные содержат неспецифированное значение. Оно не обязано быть тем, что было в участке памяти до этого. Скажем, в каком-нибудь debug режиме память может заполняться guard-значениями.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>On 11/08/10 21:57, c-smile wrote: >> FR>Ну добавь B() : t(456) {} и будет тебе изменение. >> А ты не добавляй. И не будет тебе изменение. Причем по спецификации. .>По спецификации неинициализированные переменные содержат неспецифированное значение. Оно не обязано быть тем, что было в участке памяти до этого.
Так. Давай показывай пальцем где написано что placement new обязан или хотя бы может менять member variables locations.
Он про них ничего не знает. Конструктор — знает и инициализирует только то что ты явно попросил.
С++ есть системный язык в том смысле что исповедует "design philosophy in which conflicts between performance and safety were generally resolved in favor of performance". Всякого рода копирования и иницализации стоят денег.
.>Скажем, в каком-нибудь debug режиме память может заполняться guard-значениями.
Это про placement new? Это какой такой компайлер занимается произвольной модификацией данных (которые принадлежат приложению).
В случае just new — runtime может делать все что угодно с памятью которую он *еще не отдал* тебе.
То же самое с delete — runtime в своем праве делать все что угодно с памятью *после того* как ты *явно* вызвал delete.
Какой-то детский сад право слово. Одному что-то мерещется, другому просто стрёмно...
Ну даваете уже пункты стандрта что-ли...
Здравствуйте, c-smile, Вы писали:
FR>>>>Хак чистейший, полагается на общепринятую реализацию виртуальных методов.
CS>>>Умммм... где конкретно-то хак? Нет там никакого хака.
FR>>Да там по стандарту наверняка UB.
CS>Так точно или это ты так предполагаешь?
Есть гарантии, что выравнивание у этих типов одинаковое?
Здравствуйте, night beast, Вы писали:
NB>Здравствуйте, c-smile, Вы писали:
FR>>>>>Хак чистейший, полагается на общепринятую реализацию виртуальных методов.
CS>>>>Умммм... где конкретно-то хак? Нет там никакого хака.
FR>>>Да там по стандарту наверняка UB.
CS>>Так точно или это ты так предполагаешь?
NB>Есть гарантии, что выравнивание у этих типов одинаковое?
В конкретном случае где это используется — да, есть гарантия совместимости в смысле ABI.
