Re[7]: В поисках серебрянной пули... - Языки с динамической типизацией

Приветствую!
В общем потрогал я питон и ушел обратно в перл. Ибо ООП реализовано както криво совсем, а в перле ООП хоть вообще и нету, но перл и не претендует.

Может кто подскажет кроссплатформенный скриптовый язык, с нормальной поддержкой ООП? Чтобы классы явно нужно было инициализировать, чтобы конструкторы можно было вызывать не прямым вызовом функции конструктора, а чтото по тиму C++. Ну и тд...

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

S>Может кто подскажет кроссплатформенный скриптовый язык, с нормальной поддержкой ООП? Чтобы классы явно нужно было инициализировать, чтобы конструкторы можно было вызывать не прямым вызовом функции конструктора, а чтото по тиму C++. Ну и тд...

По-моему, лучше всё-таки освоиться с питоном. Язык очень хороший, несмотря на некоторые синтаксические неудобства. Для разработки на питоне доступны неплохие IDE, питон встроен в качестве скриптового языка во многие приложения (OOo, GIMP и т.д.), плюс помимо "мейнстрима", доступны несколько сторонних реализаций питона — CPython, IronPython, есть "portable"-версии, не требующие установки в системе, Google вот ещё обещает что проект unladen-swallow позволит ускорить питон в разы.. хотя сомнительно. Но всё равно хуже не будет. Для питона имеется инструментарий для получения бинарников, не требующих установленного питона (py2exe). Есть биндинги к большинству GUI библиотек (Qt, wxwidgets, gtk). Вроде как на питоне можно писать под симбиан и какие-то смартфонооси.. но я не пробовал.

Отдельные косяки и неудобства у питона тоже есть, но в целом питон сейчас развивается очень активно и имеет хорошую поддержку со стороны различных вендоров и сообществ. В общем, я бы всё-таки советовал питон.

стеклянный
оловянный
деревянный

НО: серебряный

Здравствуйте, Mamut, Вы писали:

К>>> S>var = X(123) это? нет. А при наследовании непрямой вызов чтоли? super().__init__(abc) — это как понимать? Ладно было бы просто super(abc)...

К>>> т.е. то, что из метода __init__ вызывается родительский метод с таким же названием тебе кажется "криво совсем" и тебе нужно чтоб super вызывал автоматически одноимённый метод предка?
S>>Я просто привык к с++-подобным вызовам. Тут дело скорее в синтаксисе.

M>Так синтаксис — это дело десятое. А ООП в питоне более, чем нормальное.

Оно нормальное в любом языке этой группы: PHP, Ruby, LUA и пр.
В том смысле что все OOP парадигмы можно реализовать в них с примерно одинаковым уровнем рвотных позывов на сроку текста.

К>> S>var = X(123) это? нет. А при наследовании непрямой вызов чтоли? super().__init__(abc) — это как понимать? Ладно было бы просто super(abc)...

К>> т.е. то, что из метода __init__ вызывается родительский метод с таким же названием тебе кажется "криво совсем" и тебе нужно чтоб super вызывал автоматически одноимённый метод предка?
S>Я просто привык к с++-подобным вызовам. Тут дело скорее в синтаксисе.

Так синтаксис — это дело десятое. А ООП в питоне более, чем нормальное.

Здравствуйте, 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.

Здравствуйте, 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) проводил исследование для себя и как-то они все уложились в одну категорию.
Фичи одни и те же. Детали само собой разные.

Здравствуйте, Sheridan, Вы писали:

Z>> Полностью поддерживаю, но уверен, что Шеридана не устроит его быстродействие.

S>Можно поподробнее немного?

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>В общем потрогал я питон и ушел обратно в перл. Ибо ООП реализовано както криво совсем, а в перле ООП хоть вообще и нету, но перл и не претендует.

S>Может кто подскажет кроссплатформенный скриптовый язык, с нормальной поддержкой ООП? Чтобы классы явно нужно было инициализировать, чтобы конструкторы можно было вызывать не прямым вызовом функции конструктора, а чтото по тиму C++. Ну и тд...

Попробуйте TCL — кроссплатформенный, встроенная интеграция с C, есть куча пакетов, в том числе несколько реализаций ООП (мне больше понравился itcl, хотя есть и другие, вплоть до динамического прикручивания методов в runtime). Да, язычок специфичный, но... Но что-то в нём есть

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Курилка, вы писали:

К>> Вот скажи мне, в 7-й строчке — это прямой вызов функции конструктора?
S>var = X(123) это? нет. А при наследовании непрямой вызов чтоли? super().__init__(abc) — это как понимать? Ладно было бы просто super(abc)...

т.е. то, что из метода __init__ вызывается родительский метод с таким же названием тебе кажется "криво совсем" и тебе нужно чтоб super вызывал автоматически одноимённый метод предка?
No comments, коли уж такое вызывает "крики", то добавить нечего

Здравствуйте, c-smile, Вы писали:

CS>>>В C++ кстати тоже у объекта можно сменить класс в runtime, причем штатными методами.

FR>>Покажешь?

CS>Да легко:

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

FR>>Есть различия и огромные, ты в метаклассах питоновских поковыряйся думаю много открытий сделаешь

CS>Все зависит от уровня абстракции. Я в свое время (pre-tiscript) проводил исследование для себя и как-то они все уложились в одну категорию.
CS>Фичи одни и те же. Детали само собой разные.

Похоже ты смотрел слишком издалека.

Здравствуйте, Курилка, Вы писали:

К>

>>>> class X(object):
К>...   def __init__(self, param):
К>...     self.param = param
К>...   def show_yourself(self):
К>...     print self.param
К>... 
>>>> var = X(123)
>>>> var.show_yourself()
К>123
К>

То же но в TIScript:

class X : Object
{
   function this(param) { this.param = param; }
   function show_yourself() { stdout.println( this.param ); }
}
var x = new X(123);
x.show_yourself();

>>> 123

Для derived класса:

class Y : X
{
   function this(param) { super(param); } /* such CTOR is optional */
   function show_yourself() { stdout.print( "as Y : "); super.show_yourself(); }
}
var y = new Y(123);
y.show_yourself();

>>> as Y : 123

Если облом собирать TIScript на Linux или Windows то в Sciter можно попробовать:
test.htm

<html>
<head>
  <script type="text/tiscript">
    
  class X : Object
  {
     function this(param) { this.param = param; }
     function show_yourself() { stdout.println( this.param ); }
  }
  var x = new X(123);
  x.show_yourself();  
  
  class Y : X
  {
     function this(param) { super(param); } /* such CTOR is optional */
     function show_yourself() { stdout.print( "as Y : "); super.show_yourself(); }
  }
  var y = new Y(123);
  y.show_yourself();
  
  </script>  
</head>
<body>
</body>
</html>

Здравствуйте, 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>Угу, только ты говоришь все фрукты одинаковы

Это не я так говорю. Это ты так читаешь.

Здравствуйте, TimurSPB, Вы писали:

TSP>Ruby

Полностью поддерживаю, но уверен, что Шеридана не устроит его быстродействие.

Здравствуйте, ., Вы писали:

.>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.

Какой-то детский сад право слово. Одному что-то мерещется, другому просто стрёмно...
Ну даваете уже пункты стандрта что-ли...

placement new это средство для джедаев: http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.10
Не знаешь для чего оно и как оно работает — не используй. И всё на этом.

Здравствуйте, Курилка, Вы писали:

К>Вот скажи мне, в 7-й строчке — это прямой вызов функции конструктора?

Ну если глубоко копать это вызов метода __call__ метакласса

Приветствую, Курилка, вы писали:

К> S>var = X(123) это? нет. А при наследовании непрямой вызов чтоли? super().__init__(abc) — это как понимать? Ладно было бы просто super(abc)...

К> т.е. то, что из метода __init__ вызывается родительский метод с таким же названием тебе кажется "криво совсем" и тебе нужно чтоб super вызывал автоматически одноимённый метод предка?
Я просто привык к с++-подобным вызовам. Тут дело скорее в синтаксисе.

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, c-smile, Вы писали:

CS>>Какой-то детский сад право слово. Одному что-то мерещется, другому просто стрёмно...

FR>Стремно использовать placement new именно для того примера который ты показал.
FR>Вот тебе еще вариантик с проблемами:

Этот вариант ничуть не "хуже" чем

reinterpret_cast<B*>(a)->show();

Т.е. прострелить себе ногу вместе с головой — легко.

В реале эта штука вполне себе работает для случая:

class A 
{
  int data;
  virtual void show() {};
  virtual void hide() {};
};
class B: public A 
{
  // no data at all here
  virtual void show() { ... };
  virtual void hide() { ... };
};
class C: public A 
{
  // no data at all here
  virtual void show() { ... };
  virtual void hide() { ... };
};

Т.е. переключение осуществляется между наборами методов B и C.

FR>А так placement new вполне нормальный механизм хоть и нечасто нужный и опасный.

Ну собственно как и в Python — модификация __bases__ в runtime возможна и иногда крайне полезна, а так — ересь с точки зрения "чистого OOP".

Здравствуйте, night beast, Вы писали:

MD>>Попробуйте TCL — кроссплатформенный, встроенная интеграция с C, есть куча пакетов, в том числе несколько реализаций ООП (мне больше понравился itcl, хотя есть и другие, вплоть до динамического прикручивания методов в runtime). Да, язычок специфичный, но... Но что-то в нём есть

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

Батенька, о чем Вы? Какой Стандарт? Это что, мэйнстримовый язык, что ли, дабы Комитет созывать? Но itcl часто есть в списке предустановленных пакетов (тот же ActiveTcl от ActiveState, разные сборки линуксов и т.п.)
А чем ООП не угодило? Можно описывать классы (поля, методы, конструкторы/деструкторы), есть виртуальность, множественное наследование... Обрисуйте круг задач, на которых оно ломается?

>>> class X(object):
...   def __init__(self, param):
...     self.param = param
...   def show_yourself(self):
...     print self.param
... 
>>> var = X(123)
>>> var.show_yourself()
123

Вот скажи мне, в 7-й строчке — это прямой вызов функции конструктора?
И интересно, что ты хочешь чтоб происходило при явной инициализации классов.
Есть подозрение, что ты в динамический монастырь со статическим уставом пытаешься влезть.

Приветствую, Курилка, вы писали:

К> Вот скажи мне, в 7-й строчке — это прямой вызов функции конструктора?
var = X(123) это? нет. А при наследовании непрямой вызов чтоли? super().__init__(abc) — это как понимать? Ладно было бы просто super(abc)...

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Приветствую, blackhearted, вы писали:

b> *facepalm*

Расшифруешь?

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>В общем потрогал я питон и ушел обратно в перл. Ибо ООП реализовано както криво совсем, а в перле ООП хоть вообще и нету, но перл и не претендует.

S>Может кто подскажет кроссплатформенный скриптовый язык, с нормальной поддержкой ООП? Чтобы классы явно нужно было инициализировать, чтобы конструкторы можно было вызывать не прямым вызовом функции конструктора, а чтото по тиму C++. Ну и тд...

Я юзаю ООП в перле all day long. Посмотри в сторону Moose (http://search.cpan.org/dist/Moose/lib/Moose/Cookbook.pod).

package MyClass;
    use Moose;

    # properties
    has prop => (is => 'ro', isa => 'Str', required => 1);

__PACKAGE__->meta->make_immutable;

my $obj = new MyClass(prop => 'property value');

Еще есть MooseX::Declare. Там вообще тушите свет. Но он тормозной немного, в отличии от Moose.

    use MooseX::Declare;

    class BankAccount {
        has 'balance' => ( isa => 'Num', is => 'rw', default => 0 );

        method deposit (Num $amount) {
            $self->balance( $self->balance + $amount );
        }

        method withdraw (Num $amount) {
            my $current_balance = $self->balance();
            ( $current_balance >= $amount )
                || confess "Account overdrawn";
            $self->balance( $current_balance - $amount );
        }
    }

    class CheckingAccount extends BankAccount {
        has 'overdraft_account' => ( isa => 'BankAccount', is => 'rw' );

        before withdraw (Num $amount) {
            my $overdraft_amount = $amount - $self->balance();
            if ( $self->overdraft_account && $overdraft_amount > 0 ) {
                $self->overdraft_account->withdraw($overdraft_amount);
                $self->deposit($overdraft_amount);
            }
        }
    }

Ну, или еще Perl6. Более-менее функциональный Rakudo вышел недавно.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, blackhearted, вы писали:

b>> *facepalm*

S>Расшифруешь?

__init__ is called immediately after an instance of the class is created. It would be tempting but incorrect to call this the constructor of the class. It's tempting, because it looks like a constructor (by convention, __init__ is the first method defined for the class), acts like one (it's the first piece of code executed in a newly created instance of the class), and even sounds like one (“init” certainly suggests a constructor-ish nature). Incorrect, because the object has already been constructed by the time __init__ is called, and you already have a valid reference to the new instance of the class. But __init__ is the closest thing you're going to get to a constructor in Python, and it fills much the same role.

The first argument of every class method, including __init__, is always a reference to the current instance of the class. By convention, this argument is always named self. In the __init__ method, self refers to the newly created object; in other class methods, it refers to the instance whose method was called. Although you need to specify self explicitly when defining the method, you do not specify it when calling the method; Python will add it for you automatically.

Приветствую, Ziaw, вы писали:

Z> Полностью поддерживаю, но уверен, что Шеридана не устроит его быстродействие.

Можно поподробнее немного?

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, 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ность и чистая функциональщина как все сугубо абстрактное имеют мало шансов по жизни.
В реалии работает то что находится в золотой середине.

Здравствуйте, 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.

http://stackoverflow.com/questions/816071/prototype-based-vs-class-based-inheritance

Здравствуйте, c-smile, Вы писали:

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.

CS>http://stackoverflow.com/questions/816071/prototype-based-vs-class-based-inheritance

Есть различия и огромные, ты в метаклассах питоновских поковыряйся думаю много открытий сделаешь

Здравствуйте, 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>

Ага, только сегодня где-то у меня пробегала ссылка: http://www.kevingisi.com/2010/08/09/so-you-want-to-be-a-ruby-dev.html

Итак, вы хотите начать учить Руби. Ну, хватайте себе копию и — вперед. Только вот, какой Руби... 1.8.6, 1.8.7, 1.9.1 или 1.9.2... Есть еще JRuby, Ruby Enterprise Edition, Rubinius... И все они немного разные

Ну и т.п. Веселая статья

Здравствуйте, Mamut, Вы писали:

M>Ну и т.п. Веселая статья

Ну в питоне тоже весело 2.x vs 3.x
Хотя с выходом 2.7 уже понятно что он базовый.

Здравствуйте, 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. Все сторонние реализации совместимы с одной из них или являются форком одной из них.

Здравствуйте, 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

Здравствуйте, c-smile, Вы писали:

FR>>>>Хак чистейший, полагается на общепринятую реализацию виртуальных методов.

CS>>>Умммм... где конкретно-то хак? Нет там никакого хака.

FR>>Да там по стандарту наверняка UB.

CS>Так точно или это ты так предполагаешь?

Есть гарантии, что выравнивание у этих типов одинаковое?

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, c-smile, Вы писали:

FR>>>>>Хак чистейший, полагается на общепринятую реализацию виртуальных методов.

CS>>>>Умммм... где конкретно-то хак? Нет там никакого хака.

FR>>>Да там по стандарту наверняка UB.

CS>>Так точно или это ты так предполагаешь?

NB>Есть гарантии, что выравнивание у этих типов одинаковое?

В конкретном случае где это используется — да, есть гарантия совместимости в смысле ABI.

Здравствуйте, c-smile, Вы писали:

CS>Какой-то детский сад право слово. Одному что-то мерещется, другому просто стрёмно...

Стремно использовать placement new именно для того примера который ты показал.
Вот тебе еще вариантик с проблемами:

#include <new>
#include <stdio.h>
#include "assert.h"

class q0{};
class q1 : public q0 {};
class q2 : public q0 {};

class A : virtual public q1, virtual public q2
{
  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;
}

А так placement new вполне нормальный механизм хоть и нечасто нужный и опасный.

Здравствуйте, c-smile, Вы писали:

FR>>>>>>Хак чистейший, полагается на общепринятую реализацию виртуальных методов.

CS>>>>>Умммм... где конкретно-то хак? Нет там никакого хака.

FR>>>>Да там по стандарту наверняка UB.

CS>>>Так точно или это ты так предполагаешь?

NB>>Есть гарантии, что выравнивание у этих типов одинаковое?

CS>В конкретном случае где это используется — да, есть гарантия совместимости в смысле ABI.

раз уж заговорили про стандарт, можно ссылку на него?
я так сходу не нашел

Здравствуйте, night beast, Вы писали:

NB>>>Есть гарантии, что выравнивание у этих типов одинаковое?

CS>>В конкретном случае где это используется — да, есть гарантия совместимости в смысле ABI.

NB>раз уж заговорили про стандарт, можно ссылку на него?
NB>я так сходу не нашел

А ссылку на что собственно?

Здравствуйте, c-smile, Вы писали:

NB>>>>Есть гарантии, что выравнивание у этих типов одинаковое?

CS>>>В конкретном случае где это используется — да, есть гарантия совместимости в смысле ABI.

NB>>раз уж заговорили про стандарт, можно ссылку на него?
NB>>я так сходу не нашел

CS>А ссылку на что собственно?

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

Здравствуйте, night beast, Вы писали:

NB>Здравствуйте, c-smile, Вы писали:

NB>>>>>Есть гарантии, что выравнивание у этих типов одинаковое?

CS>>>>В конкретном случае где это используется — да, есть гарантия совместимости в смысле ABI.

NB>>>раз уж заговорили про стандарт, можно ссылку на него?
NB>>>я так сходу не нашел

CS>>А ссылку на что собственно?

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

Ты про #pragma pack или здесь? Или про то что в одной единце компиляции int могут иметь разные sizeof()? Не понимаю.

Здравствуйте, night beast, Вы писали:

NB>Есть гарантии, что выравнивание у этих типов одинаковое?

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

Здравствуйте, c-smile, Вы писали:

NB>>>>раз уж заговорили про стандарт, можно ссылку на него?
NB>>>>я так сходу не нашел

CS>>>А ссылку на что собственно?

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

CS>Ты про #pragma pack или здесь? Или про то что в одной единце компиляции int могут иметь разные sizeof()? Не понимаю.

я про то что здесь:

struct a {};
struct b {};

a * x = new a;
b * y = new(x) b;

насколько я понимаю y не обязан равняться х.
поправь, если ошибаюсь.

Здравствуйте, FR, Вы писали:

NB>>Есть гарантии, что выравнивание у этих типов одинаковое?

FR>Кстати выравнивание тут фигня, достаточно добавить один виртуальный метод (например в один из классов виртуальный деструктор)
FR>или перепутать местами объявление методов и все приплыли UB. В общем конструкция чрезвычайно хрупкая.

то что хрупкая, не спорю, но насчет перепутать местами не согласен. оператор new должен инициализировать указатель на VMT правильно.

Здравствуйте, night beast, Вы писали:

FR>>Кстати выравнивание тут фигня, достаточно добавить один виртуальный метод (например в один из классов виртуальный деструктор)
FR>>или перепутать местами объявление методов и все приплыли UB. В общем конструкция чрезвычайно хрупкая.

NB>то что хрупкая, не спорю, но насчет перепутать местами не согласен. оператор new должен инициализировать указатель на VMT правильно.

А то что вызовется совсем другой метод а не тот который просили фигня?
Ну и передача управления на другой метод возможно с другим числом и типом параметров и типом возвращаемого значения точно UB.

Здравствуйте, FR, Вы писали:

FR>>>Кстати выравнивание тут фигня, достаточно добавить один виртуальный метод (например в один из классов виртуальный деструктор)
FR>>>или перепутать местами объявление методов и все приплыли UB. В общем конструкция чрезвычайно хрупкая.

NB>>то что хрупкая, не спорю, но насчет перепутать местами не согласен. оператор new должен инициализировать указатель на VMT правильно.

FR>А то что вызовется совсем другой метод а не тот который просили фигня?
FR>Ну и передача управления на другой метод возможно с другим числом и типом параметров и типом возвращаемого значения точно UB.

тек. теперь уже я тебя не понимаю

можно пример, когда одинаково расположенные данные, но перемешанные методы дают такой эффект?
мы же после того как пересоздали объект работаем с ним по новому.

Здравствуйте, night beast, Вы писали:

FR>>А то что вызовется совсем другой метод а не тот который просили фигня?
FR>>Ну и передача управления на другой метод возможно с другим числом и типом параметров и типом возвращаемого значения точно UB.

NB>тек. теперь уже я тебя не понимаю

NB>можно пример, когда одинаково расположенные данные, но перемешанные методы дают такой эффект?
NB>мы же после того как пересоздали объект работаем с ним по новому.

Так c-smile же предлагает как раз с новым объектом работать по старому, вот чуть переделанный его
пример в котором перепутаны методы:

#include <new>
#include <stdio.h>
#include "assert.h"

class A 
{
  int t;
public:
  A(int n):t(n) {}
  virtual void test() {printf("TestA\n");}  
  virtual void show() { printf("as A:%d\n",t); }
};

class B 
{
  int t;
  virtual void show() { printf("as B:%d\n",t); }
  virtual void test() {printf("TestB\n"); }  
};

// 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;
}

Вывод:

as A:123
TestB

Здравствуйте, FR, Вы писали:

FR>>>А то что вызовется совсем другой метод а не тот который просили фигня?
FR>>>Ну и передача управления на другой метод возможно с другим числом и типом параметров и типом возвращаемого значения точно UB.

NB>>тек. теперь уже я тебя не понимаю

NB>>можно пример, когда одинаково расположенные данные, но перемешанные методы дают такой эффект?
NB>>мы же после того как пересоздали объект работаем с ним по новому.

FR>Так c-smile же предлагает как раз с новым объектом работать по старому, вот чуть переделанный его
FR>пример в котором перепутаны методы:

а, теперь понял. в исходном сообщении не обратил внимания

Здравствуйте, night beast, Вы писали:

NB>я про то что здесь:
NB>

NB>struct a {};
NB>struct b {};

NB>a * x = new a;
NB>b * y = new(x) b;
NB>

NB>насколько я понимаю y не обязан равняться х.
NB>поправь, если ошибаюсь.

Обязан, ибо должно выполняться условие:

(y + 1) - 1 == y;

Что есть

  void* p = y;
  (p + sizeof(b)) - sizeof(b) == p;

Здравствуйте, c-smile, Вы писали:

NB>>я про то что здесь:
NB>>

NB>>struct a {};
NB>>struct b {};

NB>>a * x = new a;
NB>>b * y = new(x) b;
NB>>

NB>>насколько я понимаю y не обязан равняться х.
NB>>поправь, если ошибаюсь.

CS>Обязан, ибо должно выполняться условие:
CS>

CS>(y + 1) - 1 == y;
CS>

допустим "a" выровнен по одному байту. "b" -- по 8.
оператор "new а" должен вернуть адрес, выровненный не меньше чем до 1.
оператор "new b" должен вернуть адрес, выровненный не меньше чем до 8.
как-то так.

Здравствуйте, night beast, Вы писали:

NB>допустим "a" выровнен по одному байту. "b" -- по 8.
NB>оператор "new а" должен вернуть адрес, выровненный не меньше чем до 1.
NB>оператор "new b" должен вернуть адрес, выровненный не меньше чем до 8.
NB>как-то так.

Допустим. А зачем?

На самом деле если ты внимательно посмотришь то я не использую нигде адрес возвращаемый placement new. Он никому не нужен.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую!
S>В общем потрогал я питон и ушел обратно в перл. Ибо ООП реализовано както криво совсем, а в перле ООП хоть вообще и нету, но перл и не претендует.

S>Может кто подскажет кроссплатформенный скриптовый язык, с нормальной поддержкой ООП? Чтобы классы явно нужно было инициализировать, чтобы конструкторы можно было вызывать не прямым вызовом функции конструктора, а чтото по тиму C++. Ну и тд...

Может тебе подойдет Fantom?
С ООП и кроссплатформенностью все более чем в порядке, статически типизированный, но с возможностью динамических вызовов. Можно компилировать, можно запускать прям в виде скриптов, есть repl-консоль. Язык приятный во всех отношениях, пишу на нем уже месяцев 10 и жутко доволен.

Здравствуйте, c-smile, Вы писали:

NB>>допустим "a" выровнен по одному байту. "b" -- по 8.
NB>>оператор "new а" должен вернуть адрес, выровненный не меньше чем до 1.
NB>>оператор "new b" должен вернуть адрес, выровненный не меньше чем до 8.
NB>>как-то так.

CS>Допустим. А зачем?

CS>На самом деле если ты внимательно посмотришь то я не использую нигде адрес возвращаемый placement new. Он никому не нужен.

кроме того что адрес возвращается, данные объекта размещаются по этому адресу (в том числе и VMT)

Приветствую, komaz, вы писали:

k> Может тебе подойдет Fantom?
Не распространен

avalon 1.0rc3 rev 306, zlib 1.2.3 (17.12.2009 01:06:14 MSK +03:00)(Qt 4.6.0)

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, komaz, вы писали:

k>> Может тебе подойдет Fantom?
S>Не распространен
В изначальном списке пожеланий этого не было. Нужен распространенный — ищи где-нибудь Top X most popular languages и проверяй по списку

Здравствуйте, Mr.Delphist, Вы писали:

S>>Приветствую!
S>>В общем потрогал я питон и ушел обратно в перл. Ибо ООП реализовано както криво совсем, а в перле ООП хоть вообще и нету, но перл и не претендует.

S>>Может кто подскажет кроссплатформенный скриптовый язык, с нормальной поддержкой ООП? Чтобы классы явно нужно было инициализировать, чтобы конструкторы можно было вызывать не прямым вызовом функции конструктора, а чтото по тиму C++. Ну и тд...

MD>Попробуйте TCL — кроссплатформенный, встроенная интеграция с C, есть куча пакетов, в том числе несколько реализаций ООП (мне больше понравился itcl, хотя есть и другие, вплоть до динамического прикручивания методов в runtime). Да, язычок специфичный, но... Но что-то в нём есть

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

Здравствуйте, Mr.Delphist, Вы писали:

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

MD>Батенька, о чем Вы? Какой Стандарт? Это что, мэйнстримовый язык, что ли, дабы Комитет созывать? Но itcl часто есть в списке предустановленных пакетов (тот же ActiveTcl от ActiveState, разные сборки линуксов и т.п.)

tclkit?

MD>А чем ООП не угодило? Можно описывать классы (поля, методы, конструкторы/деструкторы), есть виртуальность, множественное наследование... Обрисуйте круг задач, на которых оно ломается?

ооп не угодило тем, что каждый какой хочет такое и выдумывает.
нет чего-то стандартного вроде того же tk.
да ты самого John Ousterhout почитай.

Здравствуйте, night beast, Вы писали:

NB>ооп не угодило тем, что каждый какой хочет такое и выдумывает.
NB>нет чего-то стандартного вроде того же tk.
NB>да ты самого John Ousterhout почитай.

Типичные сожаления зрелого человека "жаль, что я не сделал это раньше". Но сути это не меняет:
1) У Вас есть возможность выбора, какой вариант реализации ООП использовать. Да, это несколько шокирует, равно как для заядлого дотнетчика информация о том, что в Java не только "тоже есть" сборщик мусора, но можно даже выбрать один из нескольких, с нужной политикой.
2) В языке TCL наружу традиционно торчат простые вещи. Маловероятно, что кто-то напишет реально полезный код и свяжет будущих пользователей конкретным ООП-пакетом.

Но в целом, мы уже приближаемся в вопросам религии, так что

	От:	Sheridan
	Дата:	09.08.10 16:02
	Оценка:	-5

От:	artem_korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	10.08.10 12:29
Оценка:	6 (1) +4

	От:	WinPooh
	Дата:	18.08.10 14:39
	Оценка:	13 (2)

	От:	TimurSPB
	Дата:	09.08.10 16:07
	Оценка:	6 (1) +2

От:	c-smile	http://terrainformatica.com
Дата:	10.08.10 18:38
Оценка:	6 (1) +1

	От:	SpaceConscience
	Дата:	09.08.10 20:17
	Оценка:

От:	Mamut	http://dmitriid.com
Дата:	10.08.10 12:51
Оценка:	+3

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	11.08.10 02:57
Оценка:

	От:	Mr.Delphist
	Дата:	16.08.10 22:05
	Оценка:	6 (1) +1

От:	Курилка	http://kirya.narod.ru/
Дата:	09.08.10 18:19
Оценка:	1 (1) +1

От:	anonymous	http://denis.ibaev.name/
Дата:	09.08.10 16:22
Оценка: