Обсуждение:Какао (API)

Эта статья уровня 5 жизненно важна и имеет рейтинг B-класса по шкале оценки контента Википедии . Она представляет интерес для следующих WikiProjects :

Apple Inc. Высокая важность This article is within the scope of WikiProject Apple Inc., a collaborative effort to improve the coverage of Apple, Mac, iOS and related topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Apple Inc.Wikipedia:WikiProject Apple Inc.Template:WikiProject Apple Inc.Apple Inc. High This article has been rated as High-importance on the project's importance scale. Computing: Software Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Low This article has been rated as Low-importance on the project's importance scale. This article is supported by WikiProject Software. This article has been automatically rated by a bot or other tool because one or more other projects use this class. Please ensure the assessment is correct before removing the |auto= parameter. An editor has requested that an image or photograph be added to this article.

Может ли кто-нибудь придумать хорошее название для этой страницы, не являющееся подстраницей? -- Тарквиний

«Cocoa (API)»? — Предыдущий неподписанный комментарий добавлен Bth ( talk • contribs ) 12:04, 27 сентября 2002 г. (UTC)

"Cocoa (ПО)" это так. Спасибо, Эд, за смелость! -- Тарквин

Ниже приведена информация из Talk:Cocoa programming:

Предложения по будущим изменениям:

• О какао можно рассказать гораздо больше.
• Следует упомянуть некоторые из фреймворков.
• Нам стоит ознакомиться с информацией на Cocoa Dev Wiki.

Эллмист

Я здесь новичок, но разве эта страница не выглядит пугающе предвзятой? Разговоры об отсутствии сбора мусора и (с моей точки зрения) бессмысленная болтовня о DOM попахивают пропагандой, в которой нет необходимости.

Как бы это было, если бы мы придерживались фактов? Cocoa основан на Objective C. Objective C не имеет глобальной автоматической сборки мусора, а вместо этого использует локальную сборку мусора через пулы автовыпуска. Как вам это? -- Jharrell 01:35 8 июля 2003 (UTC)

Однако, похоже, что в следующем релизе ObjectiveC от Apple будет сборка мусора (и я полагаю, что она будет использоваться и в Cocoa). Если вы посмотрите на исходники компилятора gnu, вы увидите это. McOsten 24 августа 2006 г.

Я только что удалил

"Таким образом, автоматически освобожденные объекты ведут себя точно так же, как объекты Java. Они автоматически удаляются сборщиком мусора, когда выходят за пределы области действия. " со страницы. Приведенное описание НЕ описывает ничего похожего на истинную природу GC Java. (Похоже, что когда переменная выходит за пределы области действия, ее можно удалить GC, в отличие от Java, где она ссылается на объект). Может ли кто-то знающий вернуть ее обратно, если она заслуживает этого? Tenbaset 07:01 11 июля 2003 (UTC)

Ну, насколько я понимаю, именно так и работает сборка мусора в Java: когда ссылка на объект выделяется в стеке (как локальная переменная), объект собирается, когда кадр стека выталкивается. Другими словами, когда поток программы выходит из области, в которой была определена локальная переменная ссылки на объект, объект, на который указывает эта ссылка, подвергается сборке мусора.

Теперь, возможно, стоит внести ясность. Когда я это писал, я намеревался указать, что для программиста автоматически освобожденные объекты ведут себя точно так же, как объекты Java. Внутренняя реализация, конечно, отличается. (Простая система подсчета ссылок Cocoa гораздо эффективнее и, следовательно, быстрее, чем причудливый и непостижимый лабиринт алгоритмов Java, но я опустил это по понятным причинам. Это статья в энциклопедии, а не маркетинговый буклет.)

Как вы думаете, восстановить, уточнить или опустить?

Джаррелл 12:38 11 июля 2003 (UTC)

Дело в том, что описание объектов autorelease не совсем соответствует поведению объектов Java. Когда ссылка на объект выходит из области действия в Java, объект может быть только собран. Две причины: во-первых, GC не гарантирует никакой своевременности (кажется, это верно и для пула autorelease); во-вторых, объект не будет утилизирован, если на него есть другие ссылки. (Так что, если я выделяю объект со ссылкой в ​​стеке, а затем назначаю ссылку на тот же объект в переменной, не находящейся в стеке, объект не будет утилизирован, пока эта и все другие ссылки не исчезнут.) У меня сложилось впечатление (возможно, ошибочное), что объекты, основанные на пуле Autorelease, всегда утилизируются, как только происходит выход из области действия — даже если есть ссылки на объекты в другом месте. Tenbaset 10:55 12 июля 2003 г. (UTC)

Я отменил некоторые правки Tenbaset . Вот почему.

• Tenbaset сказал: «Он содержит функциональность, с помощью которой программы могут создавать и взаимодействовать с графическими пользовательскими интерфейсами». Я изменил это обратно на «код», потому что «код» буквально правильный, а «функциональность» — нет. Библиотеки содержат код в форме скомпилированных функций, с помощью которых программы могут что-то делать. «Функциональность», будучи абстрактной идеей, не является чем-то, что что-то может «содержать». Плюс, «функциональность» — это обтекаемое слово. Если мы хотим изменить это на «функции», я согласен, но есть аргумент, что эти библиотеки содержат больше, чем просто функции. Поэтому я использовал общий термин «код».
• Tenbaset сказал: "... классы для общих задач, таких как обработка строк и значений, контейнеры и итерация, распределенные вычисления, обработка событий, работа в сети и другие функции, которые напрямую не связаны с графическим пользовательским интерфейсом". Я изменил это обратно на "вещи вроде". Обработка строк и значений — это задача. Другие вещи — нет. Контейнеры — это вещи. Итерация — это процесс, выполняемый с контейнером. И так далее.
• Я изменил "происходит из наследия Coca NeXTSTEP/OpenStep" обратно на "раскрывает Cocoa...", потому что префикс "NS" не является чем-то новым. Это пережиток, который присутствовал в NeXTSTEP. Поэтому я не думаю, что можно правильно сказать, что это "происходит от" чего-либо. Также исправил написание Cocoa и удалил фрагмент предложения.

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

Джаррелл 00:15 12 июля 2003 (UTC)

Возможно, не «содержат», но библиотеки «имеют» функциональность. («Функции» было бы неразумно использовать, поскольку эти библиотеки почти наверняка содержат «методы», а в некоторых языках есть четкая разница, в зависимости от точки зрения.) «Код» (как слово) мне показался неуклюжим.

"Такие вещи, как" Я думаю, что эта фраза не подходит формальному тону энциклопедии, поэтому я это изменил. "Раскрывает" имеет коннотацию, что вы обвиняете Apple в сокрытии информации, поэтому я это изменил.

Что касается DSO/DLL, какое слово используют разработчики MacOS? (Или они действительно используют несколько терминов?) (Какое расширение имеют эти файлы?) Tenbaset 10:55 12 июля 2003 (UTC)

Мне это нравится. Я все еще предпочитаю менее высокопарные "вещи вроде", но это только я. Я думаю, что формальность имеет смысл до определенного момента, за которым это просто важничанье, понимаете? В конце концов, "Никогда не используй длинное слово, если подойдет уменьшительное". Вот почему "функциональность" в моем списке. ;-)

На DSO/DLL... классические программисты Mac никогда не принимали эту концепцию. Старый ASLM (Apple Shared Library Manager) игнорировался практически всеми. (Насколько я помню, его использовал Open Transport.) Некоторые использовали вместо него CFM (Code Fragment Manager), но не слишком многие. Чаще всего ресурсы кода загружались с помощью Resource Manager для таких вещей, как плагины Photoshop. Общий код не был большой частью программирования Mac в период до Mac OS X. Microsoft создала реализацию COM для Mac и использовала ее в Office. Несколько других продуктов также использовали ее, например, более поздние версии PageMaker. Но это было все. По большей части программы Mac были просто статически связаны.

Джаррелл 15:24 12 июля 2003 (UTC)

JavaMac 18:54, 17 сентября 2006 (UTC) 18:52, 17 сентября 2006 (UTC) Ребята, может я слишком придирчив, но я нашел эту страницу на сайте Apple: http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/WhatIsCocoa/chapter_2_section_6.html, где указано, что префикс NS происходит от OPENSTEP, обратите внимание NEXTSTEP, NEXTSTEP использовал NX. Мне также показалось интересным, что Sun принимала некоторое участие. Что вы думаете? Стоит ли это исправить? [ ответить ]

OpenStep, возможно, был первым, кто использовал префикс «NS», но совершенно очевидно, что сам префикс происходит от наследия NeXTSTEP. – Mipadi 21:22, 17 сентября 2006 (UTC) [ ответить ]

Я не думаю, что это ясно. Кажется логичным, что это N eXT - S un. 128.158.145.51 20:54, 31 мая 2007 (UTC) [ ответить ]

Скорее всего, это от N eXT S TEP, поскольку большинство источников ссылаются на схему наименования. – Mipadi 17:41, 1 июня 2007 (UTC) [ ответить ]

Мне кажется, что эта страница становится чрезмерно подробной для статьи в общей энциклопедии. Я сам большой поклонник Cocoa, но даже я несколько удивлен тем, насколько эта статья выросла в последнее время, и в ней слишком много материала, который действительно будет интересен только тем, кто уже что-то знает о Cocoa. У этих людей будут гораздо лучшие ссылки для работы, чем Wikipedia! Я думаю, что есть элемент евангелизации, который заставляет страницу становиться немного чрезмерной. Я думаю, что все, кто вносит свой вклад, должны начать думать о том, как сократить ее, не теряя сути того, для чего предназначена статья, а именно, донести основные концепции и обзор Cocoa до заинтересованного мирянина. Другая проблема с тем, что статья такая длинная, заключается в том, что она на самом деле немного плотная и отталкивающая для чтения, что является противоположностью евангелизации. Я думаю, что многое можно заменить подходящими внешними ссылками на документацию Apple. Грэм 11:02, 17 апреля 2005 г. (UTC)

Согласен, что статья, хотя и хорошо написана, не совсем читается как статья энциклопедии. Возьмем, к примеру, это предложение. "Читатели, знакомые с системами быстрой разработки приложений (RAD), такими как Visual Basic или Borland Delphi, могут быть поражены некоторыми параллелями между их системами и Cocoa". Это звучит как учебник или веб-сайт, но не как энциклопедия. Когда вы начали использовать фразы вроде "читатели", давайте рассмотрим это и это, у вас могут быть следующие опции для управления памятью (ради бога, читатели не пишут приложения Cocoa!) и т. д., это должно плохо пахнуть, очень плохо. Конечно, сложная часть в том, как сохранить хорошую информацию; часто сложнее удалять что-то, чем добавлять. -- Taku 17:04, 17 апреля 2005 г. (UTC)

Почему название этой статьи было изменено, очевидно, без консультации (если и была консультация, где она проводилась? - У меня в списке наблюдения большинство статей, связанных с Apple, и я не успел ничего увидеть об этом). API означает APPLICATION programming Interfaces (интерфейсы программирования приложений). Cocoa - это НЕ API, это фактически целая операционная система, вы можете написать что угодно, от инструментов командной строки до драйверов, системных служб, плагинов, панелей настроек, скринсейверов и да, даже приложений. Предыдущее название кажется мне подходящим, хотя, если это связано с другим обсуждением соглашений об именовании статей, связанных с Mac, то Cocoa (Macintosh) было бы более уместным. Грэм 23:30, 27 апреля 2005 г. (UTC)

Я собираюсь пройтись и немного поработать над этой статьей. Надеюсь, что это вызовет одобрение людей — проблема, как я ее вижу, в том, что в статье слишком много деталей и пропаганды. Хотя я большой поклонник Cocoa и использую его ежедневно в своей работе, я чувствую, что эта статья не в том ключе. Она должна донести, что такое Cocoa, не увлекаясь попытками его евангелизации. Я внесу изменения в течение следующего дня или двух — дайте мне шанс, хорошо? Грэм 00:04, 19 мая 2005 (UTC) [ ответить ]

В этой статье говорится о декабре 96-го, но в статье NeXT говорится о начале 97-го. Что это значит? WAvegetarian 21:48, 18 октября 2005 (UTC) [ ответить ]

Я узнал об этом на Рождество (96-го), но не думаю, что остальной мир узнал об этом до начала 97-го. WilliamJonShipley 10:32, 11 декабря 2005 (UTC) [ ответить ]

http://www.news.com/Apple-acquires-Next,-Jobs/2100-1001_3-256914.html от 20 декабря 1996 г.

Дата 20 декабря является правильной для объявления о намерениях. Слияние было окончательно завершено 7 февраля после одобрения регулирующих органов и решения других вопросов. http://www.thefreelibrary.com/Apple+Computer,+Inc.+Finalizes+Acquisition+of+NeXT+Software+Inc.-a019104632

Iamleeg (обсуждение) 13:32, 3 мая 2013 (UTC) [ ответить ]

Я работаю над вики-книгой, которая является руководством для начинающих по программированию с помощью Cocoa. На момент написания это всего лишь очень ранний черновик, с множеством опечаток и других несоответствий. Надеюсь, кто-то еще заинтересуется и поможет! Вот ссылка: [1]. Грэм 23:22, 29 января 2006 (UTC) [ ответить ]

«...называется кодированием «ключ-значение» (KVC). Это позволяет искать или изменять фрагмент данных или свойство объекта во время выполнения по имени»

Здесь не говорится, может ли атрибут быть создан или удален во время выполнения, как в некоторых объектах на основе хэша в Perl. — Предыдущий неподписанный комментарий добавлен 82.67.217.13 (обсуждение) 09:22, 30 июня 2006 г. (UTC)

Атрибуты могут быть созданы или удалены во время выполнения, но объект должен быть специально настроен для работы таким образом. Так работает NSDictionary (объект на основе хеша).

В статье не говорится, предоставляет ли Cocoa хук для регистрации сущностей, таких как дескрипторы файлов, для мониторинга циклом событий. Эта функция необходима для использования языка сценариев и их библиотек. Например, POE в Perl может иметь свой собственный цикл событий или регистрировать сущности во внешнем цикле (здесь цикл событий Cocoa) для мониторинга. —Предыдущий неподписанный комментарий добавлен 82.67.217.13 (обсуждение) 09:22, 30 июня 2006 г. (UTC)

Было бы неплохо включить некоторую информацию, которую обычные конечные пользователи сочтут интересной и понятной. Например, «приложения Cocoa работают быстрее, чем приложения Carbon» или «все приложения Cocoa используют одинаковые кнопки и шрифты», если это правда; я не знаю. —Предыдущий неподписанный комментарий добавлен Ephilei ( talk • contribs ) 23:37, 8 октября 2007 (UTC) [ ответить ]

Обычные пользователи не должны найти ничего интересного в этом смысле в API.

Изображение:Cocoa dev screen.png используется в этой статье. Я заметил, что на странице изображения указано, что изображение используется в рамках добросовестного использования , но нет объяснения или обоснования того, почему его использование в этой статье Википедии является добросовестным использованием. В дополнение к шаблону добросовестного использования , вы также должны написать на странице описания изображения конкретное объяснение или обоснование того, почему использование этого изображения в каждой статье соответствует добросовестному использованию .

Пожалуйста, перейдите на страницу описания изображения и отредактируйте ее, включив обоснование добросовестного использования . Использование одного из шаблонов на Wikipedia:Fair use reasone guideline — это простой способ убедиться, что ваше изображение соответствует политике Wikipedia, но помните, что вы должны заполнить шаблон. Не вставляйте просто пустой шаблон на страницу изображения.

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

BetacommandBot ( обсуждение ) 21:14, 13 февраля 2008 (UTC) [ ответ ]

Есть ли официальное слово о произношении, и следует ли добавлять фонетическую версию в первую строку? Я всегда предполагал, что это произносится как "ко-ко", как горячий шоколад, но я также слышал "ко-ко-ух" или "ко-ко-а". — Иоанна 19:23, 27 февраля 2008 (UTC)

это ko-ko, послушайте любой основной доклад или демонстрацию — Предыдущий неподписанный комментарий добавлен Petchboo ( обсуждение • вклад ) 15:57, 5 марта 2008 (UTC)[ отвечать ]

Добавьте его, скорее! — Предыдущий неподписанный комментарий добавлен 129.120.94.106 (обсуждение) 18:24, 6 марта 2008 (UTC) [ ответить ]

почему бы вам не добавить его? — Предыдущий неподписанный комментарий добавлен Petchboo ( обсуждение • вклад ) 14:35, 10 марта 2008 (UTC)[ отвечать ]

На дворе ноябрь 2008 года, и все еще ничего? Немного информации в статье Cocoa Touch , в которой есть предложение по слиянию, но нет обсуждения. Предлагаю раздел о Cocoa Touch со ссылкой на основную статью или раздел о различиях — различий много, хотя я с ними не знаком. —[ точки с запятой ]— 21:36, 20 ноября 2008 (UTC) [ ответить ]

«Используя только встроенные функции, можно написать приложение текстового редактора всего за 0 строк кода. С новыми объектами контроллера это число может сократиться до нуля».

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

Вы можете просто перетащить текстовое поле в окно, и тогда оно сделает почти все основные вещи, которые может сделать настоящий редактор (шрифты, цвета, размеры, линейка и т. д.), за исключением, может быть, сохранения. Но я не знаю, нужно ли нам включать это в статью. -- Thekmc ( обсуждение ) 19:21, 5 марта 2011 (UTC) [ ответить ]

Может ли кто-нибудь написать очень подробное объяснение разницы между Cocoa и Carbon, и как они сравниваются и противопоставляются? Я не очень разбираюсь в этой области. Я думаю, что это принесет пользу людям, читающим эту статью, особенно если они ее выбирают. Может быть, когда-нибудь создать страницу «Различия между Cocoa и Carbon»? —Предыдущий неподписанный комментарий добавлен Geek 2.0 ( обсуждение • вклад ) 01:23, 29 октября 2008 (UTC) [ ответить ]

Хорошая идея, но, спасибо, ее слишком легко найти в Google.

http://www.osnews.com/story/661/What_is_the_Difference_Between_Carbon_and_Cocoa — Предыдущий неподписанный комментарий добавлен 2001:558:6045:56:A494:E24D:2C11:BD29 ( обсуждение ) 23:03, 27 июля 2018 (UTC) [ ответить ]

Следующее предложение нуждается в обновлении, отражающем изменения AppleScript в Snow Leopard: «AppleScript Studio, часть инструментов Xcode от Apple, позволяет писать (менее сложные) приложения Cocoa с использованием AppleScript». ( 91.46.121.29 (обсуждение) 15:12, 12 сентября 2009 (UTC)) [ ответить ]

 Сделано -- Thekmc ( обсуждение ) 14:47, 5 марта 2011 (UTC) [ ответить ]

В первом предложении говорится, что «Cocoa — один из собственных объектно-ориентированных языков прикладных программ Apple Inc.», но это не язык программирования, а фреймворк. Khatchad (обс.) 05:22, 13 августа 2010 (UTC)Raffi 13.08.2010 [ ответить ]

Это замечание похоже на мнение или оригинальное исследование: «Для конечных пользователей приложения Cocoa считаются написанными с использованием среды программирования Cocoa. Такие приложения обычно имеют отличительный вид, поскольку среда программирования Cocoa автоматизирует многие аспекты приложения для соответствия рекомендациям Apple по пользовательскому интерфейсу».

Приложение Carbon вполне может вести себя точно так же, как приложение Cocoa, или приложение Cocoa может быть плохо написано и демонстрировать непоследовательное поведение. Майк Ричардсон ( обсуждение ) 20:20, 6 ноября 2012 (UTC) [ ответить ]

Но в обоих случаях разработчику приходится прикладывать дополнительные усилия, чтобы добиться этого.

Может быть, Swift следует упомянуть. Впервые я услышал о Cocoa, когда исследовал Swift для проекта. Согласно как минимум одному источнику ^[1], Cocoa работает со Swift, поэтому, возможно, Swift следует упомянуть вместе с другими языками, упомянутыми в статье. 184.75.159.160 (обсуждение) 00:04, 6 июня 2014 (UTC) [ ответить ]

Поскольку у Yellow Box нет отдельной веб-страницы, я пишу здесь.

Yellow Box для Windows можно найти в WebObjects для Windows, Yellow Box Developer Preview, OPENSTEP Enterprise для Windows, Rhapsody DR2 для Windows, и не совсем понятно, какой между ними порядок. Один человек показал скриншоты "Project Builder" для Window на разных Yellow Box.

OPENSTEP Enterprise 4.2 (1996?) v300.2
Rhapsody DR2 (1998) v332.2
WebObjects 4.5.1 (2001) содержат Yellow Box 1.0, v365
YellowBox 5.1 DR2 (?), v?

OCTAGRAM ( обсуждение ) 22:45, 22 ноября 2014 (UTC) [ ответить ]

Yellow Box может быть недостаточно значимым, чтобы иметь свою собственную страницу в Wikipedia. Однако, OpenStep имеет свою собственную страницу в Wikipedia. Guy Harris ( обсуждение ) 23:14, 22 ноября 2014 (UTC) [ ответить ]

Недавно была работа над привязкой Cocoa с открытым исходным кодом в C под названием Silicon[2]. Может быть, ее можно добавить в список других привязок Cocoa[3]? КоллегаРайли (обсуждение) 20:17, 9 апреля 2023 (UTC) [ ответить ]