Комментарии 22
Тогда уж прикручивайте своё чудо к Objective-J
+1
Библиотеки Objective-C лежат в основе интерфейса MacOS X и iOS.
Собственно, этот мост создан для того, чтобы сделать возможным написание приложений с графическим интерфейсом прямо на Node.
Собственно, этот мост создан для того, чтобы сделать возможным написание приложений с графическим интерфейсом прямо на Node.
+1
Это всё понятно, objective-j в свою очередь это Objective-C подобный язык обёрнутый в JS, логично пользоваться не только функционалом Foundation, но и внешним представлением схожим с родным для платформы. Это позволит использовать оригинальный код приложений с MacOS прямо внутри Node.js (хотя я понятия не имею кому вообще понадобилось через Node пинать OS)
+1
Вроде бы на iOS категорически запрещены подобные среды выполнения? Или оно полностью компилирутеся в объектный код, без единого намёка на JavaScript?
это даже не знаю как назвать.
понятно, что можно сделать свою функцию и будет вроде
но блин, почему первая строка — «обычная» а вторая — нет? зачем это знать разработчику?
разве не может эта обёртка сама решить, когда нужно делать NSString, а когда нет?
про поддержку IDE даже боюсь спросить
var string = $.NSString('stringWithUTF8String', 'Hello Objective-C World!');
это даже не знаю как назвать.
понятно, что можно сделать свою функцию и будет вроде
console.log('%s', s('Hello Objective-C World!'))
но блин, почему первая строка — «обычная» а вторая — нет? зачем это знать разработчику?
разве не может эта обёртка сама решить, когда нужно делать NSString, а когда нет?
про поддержку IDE даже боюсь спросить
0
Согласен с вами, интерфейс пока подкачал.
0
var string = $.NSString('stringWithUTF8String', 'Hello Objective-C World!');
это даже не знаю как назвать.
Я не гуру в javascript, но как это может выглядеть иначе? Просто интересно.
0
тут вопрос не в Java-script. Я, скорее, к общей логике и разумному смыслу взываю.
Дляпрограммиста человека важно видеть суть. Суть — строка Hello Objective-C World!. Всё остальное — это шум, информационный мусор.
Я готов принять кавычки вокруг текста — это почти неизбежно в языках программирования.
Но принять остальные 38 (тридцать восемь) символов, необходимых лишь для того, чтобы компьютер понял такую простейшую операцию, я не согласен.
Иначе это может выглядеть так:
где log и остальной текст показаны разным цветом для пущего удобства.
я не шучу, для такого представления операций не требуется даже не-текстовое представление программы. Некоторые развитые языки программирования отлично понимают такую запись (например, в Matlab так и есть, только в стандартной библиотеке
Давайте сравним ещё раз:
и
Для
Я готов принять кавычки вокруг текста — это почти неизбежно в языках программирования.
Но принять остальные 38 (тридцать восемь) символов, необходимых лишь для того, чтобы компьютер понял такую простейшую операцию, я не согласен.
Иначе это может выглядеть так:
log Hello Objective-C World!
где log и остальной текст показаны разным цветом для пущего удобства.
я не шучу, для такого представления операций не требуется даже не-текстовое представление программы. Некоторые развитые языки программирования отлично понимают такую запись (например, в Matlab так и есть, только в стандартной библиотеке
disp
вместо log
).Давайте сравним ещё раз:
log Hello Objective-C World!
и
console.log('%s', $.NSString('stringWithUTF8String', 'Hello Objective-C World!'));
-2
Если рассматривать исключительно данный гипотетический пример, то возможно. Но вообще суть не просто строка, это вызов метода класса NSString для создания строки которая затем будет автоматически удалена, с тем же успехом может быть и такое например:
И еще примерно с пару десятков только стандартных способов создания строки, и это не считая того, что какие-то способы могут быстро множиться в других модулях через категории, по сути поведение не определено. И теперь множим это на каждый из существующих классов. Можно конечно определенные какие-то наиболее популярные вещи и переделать, но к чему? Код станет сложнее поддерживать, сложнее переносить туда-обратно.
var string = $.NSString('stringWithContentsOfFile', '/var/log/system.log');
илиvar string = $.NSString('alloc')('initWithData', data,
'encoding', NSWindowsCP1251StringEncoding);
И еще примерно с пару десятков только стандартных способов создания строки, и это не считая того, что какие-то способы могут быстро множиться в других модулях через категории, по сути поведение не определено. И теперь множим это на каждый из существующих классов. Можно конечно определенные какие-то наиболее популярные вещи и переделать, но к чему? Код станет сложнее поддерживать, сложнее переносить туда-обратно.
+2
Спасибо! Не знал про такие возможности.
Как-то привык что в моём server-java-мирке строки всегда в правильной кодировке, а об ручном управлении памятью вспоминать приходится лишь в местах, критичных по производительности.
Ну, и вообще что в строку можно загрузить файл — даже не приходило в голову =) в Java для этого нужно написать строчек 5. Зато там явно происходит управление IO и перепутать строку (которая доступна моментально) с содержимым файла (которое вообще может и сломаться) не получится.
Интересно. Это как в Китай съездить — совсем другой взгляд на привычне вещи
Как-то привык что в моём server-java-мирке строки всегда в правильной кодировке, а об ручном управлении памятью вспоминать приходится лишь в местах, критичных по производительности.
Ну, и вообще что в строку можно загрузить файл — даже не приходило в голову =) в Java для этого нужно написать строчек 5. Зато там явно происходит управление IO и перепутать строку (которая доступна моментально) с содержимым файла (которое вообще может и сломаться) не получится.
Интересно. Это как в Китай съездить — совсем другой взгляд на привычне вещи
0
Как-то привык что в моём server-java-мирке строки всегда в правильной кодировке
Ну это вы зря, вы наверное просто не сталкивались например с необходимостью разбирать какой-нибудь бинарный формат. Даже используя специальные частотные алгоритмы для конкретного языка, всеравно остается шанс ошибки. А смысл здесь в создании строки из каких-то raw данных, частный случай.
Про загрузку впрочем тоже просто пример, как открыть файл и подгрузить его — ну наверное с десятка два способов.
0
Мне показалось или вы действительно далеки от программирования?
0
=) вам показалось, я неплохой программист.
Просто я далёк от ObjectiveC и не очень разделяю его философию.
Я не буду писать
Я заплачу чуть-чуть процессорного времени и буду использовать язык с автоматическим управлением памяти.
Просто я далёк от ObjectiveC и не очень разделяю его философию.
Я не буду писать
var string = $.NSString('alloc')('initWithData', data, 'encoding', NSWindowsCP1251StringEncoding)
, чтобы объявить строку, котоорую потом удалена из памяти.Я заплачу чуть-чуть процессорного времени и буду использовать язык с автоматическим управлением памяти.
+1
Говоря про управление памятью, тут есть три подхода на самом деле:
1. классический с ручным управлением
2. автоматический сборшик мусора
3. автоматическая система которая сама определяет когда и что удалить, создавая за программиста соответствующий код в нужных местах при компиляции. Получается удобно как при автоматическом сборщике, но при этом быстро и почти так же эффективно как при ручном управлении (не будет работать с этой библиотекой ясное дело).
Но абсолютное большинство все же предпочитает первый вариант, оно не сложно на самом деле, зато позволяет точно планировать каждый чих.
1. классический с ручным управлением
2. автоматический сборшик мусора
3. автоматическая система которая сама определяет когда и что удалить, создавая за программиста соответствующий код в нужных местах при компиляции. Получается удобно как при автоматическом сборщике, но при этом быстро и почти так же эффективно как при ручном управлении (не будет работать с этой библиотекой ясное дело).
Но абсолютное большинство все же предпочитает первый вариант, оно не сложно на самом деле, зато позволяет точно планировать каждый чих.
0
На деле мы все предпочитаем второе… кстати, все браузеры построены на втором принципе (JS Engine).
0
Я говорил про obj-c программистов, среди них сборщиком мусора пользуются единицы, да и то большей частью пришедшие с других платформ, вроде java/.net, да и опять же в легких прикладных проектах полагающихся только высокоуровневые фреймворки.
Про браузеры не понял, javascript конечно имеет сборшик мусора, но сами движки и браузеры устроены более сложно и там ручное управление, да и до сих пор часть кода все равно на ассемблере, взять хотя бы гугловский v8.
Про браузеры не понял, javascript конечно имеет сборшик мусора, но сами движки и браузеры устроены более сложно и там ручное управление, да и до сих пор часть кода все равно на ассемблере, взять хотя бы гугловский v8.
0
> но блин, почему первая строка — «обычная» а вторая — нет?
по той же причине, почему «строка обычная», а @«строка `необычная`».
по той же причине, почему «строка обычная», а @«строка `необычная`».
+1
А www.appcelerator.com по тому же принципу работает? Я вот думаю его купить. Пока самый развитый претендент на крос-платформенность вроде как.
+2
Т.е. купить он же бесплатный был?
0
Сам фреймворк — да. Саппорт и тренинг — нет. www.appcelerator.com/company/how-to-buy/
0
Точнее вот — www.appcelerator.com/products/plans-pricing/
0
НЛО прилетело и опубликовало эту надпись здесь
Вызовы методов — это не очень интересно.
Я вот так и не понял, можно ли, и если можно, то как сделать наследование, например, от какого-нибудь view controller'а, реализовать протокол и сделать этот класс делегатом чего-нибудь?
Я вот так и не понял, можно ли, и если можно, то как сделать наследование, например, от какого-нибудь view controller'а, реализовать протокол и сделать этот класс делегатом чего-нибудь?
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NodObjC — мост между Objective-C и Node.JS