Центр информации по операционным системам: Форумы / Разное / Objective-C -- плюсы и минусы

Центр информации по операционным системам :: Форумы :: Общие :: Разное		<< Предыдущая тема \| Следующая тема >>
Objective-C -- плюсы и минусы

Переход на страницу 1 2 3 [4] 5
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

ossadchy

Понедельник 26.11.2007 23:18

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

2leto: это замечательно, у меня появился единомышленник... думаю разработка, которая зреет в моей лаборатории прийдется Вам по душе...
сам был очень польщен стройностью и мощью данного языка.

2Hmmm: ну в принципе посылку сообщений можно и в C реализовать... суть в том насколько БАЗОВЫЕ средства языка приспособлены решать повседневные задачи... может задачи у меня такие, может я такой

Поверьте ничего против C++ не имею, просто люблю вещи попроще...

Наверх

ossadchy

Понедельник 26.11.2007 23:22

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

2leto: что именно вы считаете корявым в синтаксисе?

Наверх

leto

Вторник 27.11.2007 10:30

ID пользователя #960

Зарегистрирован: Понедельник 26.11.2007 17:57
Местонахождение: Moscow
Сообщений: 3

ossadchy:

разработка может и придется, а что за разработка?

корявым по-началу выглядел синтаксис определния классов и иже с ними (методов, протоколов). мне кажется, что определение классов а-ля С++ и ява более синтаксически красивое... но это все субъективно. щаз мне уже видятся все эти @interface нормальными конструкцям. даже развитие objc 2.0 где можно сообщения посылать через точку мне кажется излишним

т.ч. лично для меня objc совершенно рулезный язык

мне он понравился больше чем с++ и ява.

Наверх

ossadchy

Вторник 27.11.2007 10:57

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

В чем суть моих изменений:
- исключение Cшных структур, enum и т.д.
- определение классов в виде
class A extends B
-(void)method1;
-method2: anArg;
end
- строки -- объекты(без всяких @)
- все структуры данных служащие для интроспекции станут объектами
- введение понятия "блоков кода", т.е. станут доступны конструкции типа
[collection foreach: { :a | [a anyaction]; }];
что сделает ненужными конструкции в духе ObjC2.0, которые есть шагом в сторону "от" идеологии языка. в данный момент есть достаточно эфективная реализация блоков в POC.
- подход подобный Smalltalk -- программисту сразу доступны все классы установленные в системе, без всяких import, include и т.д.. точно так же отпадет необходимость в использовании заголовочных файлов
- типы данных в духе C# и Java -- их размеры четко определены и одинаковы на всех платформах:
* char
* byte
* sbyte
* short
* ushort
* int
* uint
* long
* ulong
* bool
- невозможность операции отличной от операции посылки сообщения над выражениями типа 'id'(который тоже являются базовым типом). невозможность приведения типа id к другим типам, невозможность приведения других типов к типу id. т.е. -- типобезопасность.
- исключение конструкций @protocol, категория, статической типизации... все это абсолютно не нужные вещи для ОО-языка. Ведь @protocol был введен для того чтоб сделать доступными определения селекторов для классов использующих или реализующих данный протокол. При подходе, подобному image-based approach в smalltalk, все это не нужно.. просто шли любое сообщение определенное в системе любому классу.
- глобальные объекты, на одном уровне с классами будет возможность определять неизменяемые общедоступные объекты(возможно и значения примитивных типов). их роль - заменить константы и значения enum.
- поддержка RAD: введение свойств объектов, возможно это будет просто декларативный элемент языка и эти определения будут сохраняться для использования в IDE. на стадии обдумывания.
- autoboxing/unboxing - вместо объекта можно передать примитивное значение, которое будет преобразовано в объект существующего класса.. или наоборот... основа реализации -- динамическая генерация функций-заглушек средствами JIT-библиотек.

в данный момент компилятор основан на POC(Portable Objective-C compiler) что дало уже практически полнофункциональный инструмент )

язык останется компилируемым, все изменения и доработки делаются с точки зрения упрощения языка и его использования, при сохранении присущей ObjC достаточно высокой производительности. вместе с тем не исключено, что в перспективе будет написана VM для этого языка..

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

Вот так вот.. кодовое название платформы и языка: LIME.

[ Редактирование Вторник 27.11.2007 11:09 ]

Наверх

leto

Вторник 27.11.2007 11:16

ID пользователя #960

Зарегистрирован: Понедельник 26.11.2007 17:57
Местонахождение: Moscow
Сообщений: 3

ossadchy: ой... а зачем ты язык изменил? имхо это тупик. objc нужен на 99% только эппл и для программинга под мак ос х. твое изменение языка, к сожалению, не будет иметь никакого практического значения.

и вообще, путь развития компов устлан трупам языков программирования

не добавляй еще один. objc как он есть -- нормальный язык.

Наверх

ossadchy

Вторник 27.11.2007 14:41

ID пользователя #941

Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181

просто цель: сделать язык типобезопасным, как Java, C#.. убрать атавизмы C(хотя этот язык люблю, уважаю, использую). Хочется сделать его удобней и проще... в моем понимании... делаю больше всего для себя, если кому-то понравится, ничего против иметь не буду.. исходники прятать и тому подобными вещами заниматься не собираюсь.

мое изменение языка нужно на 99% мне для моих задач

[ Редактирование Вторник 27.11.2007 14:45 ]

Наверх

grizlyk

Среда 24.09.2008 14:00

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

ossadchy написал(а) ...

Появляется возможность реализовать динамическую обработку сообщений... появляется возможность без доп. средств использовать классы реализованные на Objective-C в скриптовых языках и окружениях... органично вписывается динамическая подгрузка классов... отсутствие необходимости приведения типов(в случае неиспользования шаблонов, это приходится часто делать) делает код более удобочитаемым. Вот в таком духе

Objective-С это язык, который приводит к ошибкам типа (это чисто ошибка программиста) во время выполнения, т.е. передает нагрузку разработчика на потребителя продукта. Язык со строгой типизацией не только проверяет такие несоответствия, но и позволяет выполнить часть вычислений до реального выполнения программы пользователем.

Чтобы отказаться от типизации нужны веские причины, в чем они заключаются? Сопутствующий вопрос, если вы уверены, что ошибка типа во время выполнения не возникнет, то почему не воспользовались типизацией, что помешало?

С++ не идеально работает с типизаций, но С++ можно просто изменить.

Наверх

grizlyk

Среда 24.09.2008 14:05

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

ossadchy написал(а) ...

по-моему
if ([anObject isKindOf: Class])

выглядит намного приличней(как и аналогичный код на JAVA)

Введение в С++ диалектов поможет решить эту проблему.

Наверх

grizlyk

Среда 24.09.2008 14:58

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

Chizh написал(а) ...

Сложными обычно являются низкоуровневые ЯП (Аsm, C, С++, ObjC), потому что низкоуровневой код сложней по определению, чем код написанный на высокоуровневом ЯП. Но для ядра нужны именно такие языки, потому что высокоуровневых языков работающих напрямую с аппаратурой быть не может.

1. (низкоуровневые...) Нельзя сравнивать С++ с С и уж тем более с ассемблером, потому как С++ поддерживает новую для них парадигму программирования - ОО.

2. (высокоуровневых...) Как раз ООП (своей продвинутой абстракцией и инкапсуляцией) позволяет совместить абстрактный подход и язык ассемблера, вот пример этого принципа:

//high level interface
//***************

class Tdevice
{
public:
void native_access();
};

//high level inplementation
//*********************
#include high level interface
#include low level implementation

void
Tdevice::native_access()
{
low_level_access();
...
low_level_access();
...
}

//low level implementation
//********************

namespace Ncommon{
inline void low_level_access()
{
int a,b,s,d;
for(), get, put
}}

namespace Nx86{
inline void low_level_access()
{
asm{}
}}

namespace N68x{
inline void low_level_access()
{
asm{}
}}

#ifdef TARGET
//принцип ясен
using namespace N##TARGET
#else
using namespace Ncommon
#endif

//END

Скажем честно, что "Страуструпу и К" не удалось полностью реализовать в С++ ОО парадигму из-за того пути, которым они пошли в эволюции языка, поэтому им пришлось выкручиваться и выдумывать парадигму "обобщенное программирование", которое по своей сути обычное структурное, с элементами ОО модели, на сколько ОО поддерживается С++.

По крайней мере мне не попадались теоретические работы, обосновывающие методологию проектирования программ для парадигмы "обобщенного прогаммирования".

Но проблемы конкретной реализации ОО модели в С++ это не проблема языка, язык можно исправить, даже породить клон, если уж на то пойдет дело.

категорий языков ОБЩЕГО НАЗНАЧЕНИЯ пригодных и непригодных для написания ОС

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

Наверх

grizlyk

Среда 24.09.2008 15:05

ID пользователя #757

Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72

ossadchy написал(а) ...

просто цель: сделать язык типобезопасным

Вообще ничего не понял. Или язык будет гибким как Smalltalk или типобезопасным, как С и его потомки.

Наверх

Переход на страницу 1 2 3 [4] 5
Перейти: Наверх