>Всё упирается в DOM-ы, которые придётся изучать
на самом деле достаточно десятка методов и свойств. я, например, досконально этот идиотский API не знаю. %-)

ещё полезно поучить XPath, чтобы удобно ноды выбирать.

>прочитать же и понять код на Яваскрипте я могу и без подготовки
хихик.

function A () {
  function B () {
    var i = 5;
    return [(i++)+(arguments.length?arguments[0]:0), arguments.callee, function () { return (i++); }];
  }
  var t = B(2);
  var z = 7+t[0]+t[1]()[0];
  z += t[2]()+B()[0]+t[2]();
  return z;
}

результат вызова A()? %-)

(Reply to this) (Parent) (Thread)

да, поддерживаю с xpath,
на него достаточно часа.

в DOM тоже важна идея,
а не реализация - нужен
он лишь для траверса по
XML-дереву, а также для
манипулирования его узлами.

(Reply to this) (Parent) (Thread)

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

>в DOM тоже важна идея,
>а не реализация
но логика ввода/именования методов и свойств там совершенно марсианская.

(Reply to this) (Parent) (Thread)

кстати, про xpath: как выделить нод,
внутри которого выполнены критернии,
например, тэг А, который содержит
определённый текст (заселектить
нужно именно А, а не текст внутри)?

(Reply to this) (Parent) (Thread)

это тебе, я полагаю, надо использовать XPath Axes. например:
//tr[descendant::a[@class='forumlink']]
находит ячейку таблицы, которая содержит ссылку с классом forumlink.

(Reply to this) (Parent)

В общем, в зависимости от того, что считать подготовкой, я разобрался скорее всего с подготовкой:)

Сборку jsshell, наверное, следует считать подготовкой.

Расстановку print() и манипуляции со скобками — тоже, наверное:)

Сперва я зашёл в тупик с вызовом t[2]: думал, ругнётся на отсутствие i.

Потом началась порнография с использованием jsshell…

Спасибо за пример, ты в чём-то прав, но возраст не позволил мне послать неправильный ответ
1. о том, что функция ругнётся на отсутствие i,
2. вторая же версия тоже оказалась неверна (B(...)[2] берёт значение i, дошедшее до неё на момент определения функции),
3. на самом деле f=B(...)[2] держит у себя ?статическую? переменную, создаваемую при вызове B, и при каждом вызове f её увеличивает (но для разных вызовов B переменные эти разные):)

(Reply to this) (Parent) (Thread)

пример, конечно, насквозь artificial, зато показывает заморочки с closures.

для «3» — она не «статическая», она «замкнутая». при вызове функции js создаёт «замыкание» со всеми описаными локальными переменными (но не с аргументами функции! я на этом погорел однажды %-), и дальше этот «микрокосм» живёт себе отдельно. тут бы по совету phantom тебе пригодился опыт со scheme, там замыкания достаточно широко используются. в компилируемых же языках такого механизма в принципе нет (в java есть, но сделано через жопу, многословно и толком всё равно не работает %-).

(Reply to this) (Parent) (Thread)

То, что написал я про "статические" абсолютно верно (я же описал механизм, это то же самое, то, что она не является статической в смысле, например, Цепепе, итак ясно):)

Употреблять слово "замкнутая" — та же фигня, я написал "статическая" как человек новый.

(Reply to this) (Parent) (Thread)

>То, что написал я про «статические» абсолютно верно
да, но лучше применять правильный термин. в этом и был смысл моего уточнения. %-)

а то путаница будет, «статическая» традиционно обозначает static из цэ.

хотя «замкнутая» мне тоже не нравится. но другого нет пока, афаик.

(Reply to this) (Parent) (Thread)

(Reply to this) (Parent)

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

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

>в компилируемых же языках такого механизма в принципе нет

это в корне неверное утверждение.
замыкания есть почти во всех "свежих"
компилируемых языках, таких как
D, Nemerle, Scala и даже Visual Basic

(Reply to this) (Parent) (Thread)

>в компилируемых же языках такого механизма в принципе нет

это в корне неверное утверждение.
замыкания есть почти во всех "свежих"

Конечно неверное.

Утверждение не моё, но ketmar, наверное, прочтёт этот твой комментарий.

Возможно, в ближайшие годы во FreePascal могут появиться "замыкания".

(Reply to this) (Parent) (Thread)

>но ketmar, наверное, прочтёт этот твой комментарий.
таки пропустил. %-)

http://lj.rossia.org/users/phantom/33098.html?thread=377418#t377418

>Возможно, в ближайшие годы во FreePascal могут появиться «замыкания».
это вряд ли. скорее таки нечто вроде «делегатов», которые ублюдочны по самой идее.

(Reply to this) (Parent) (Thread)

скорее таки нечто вроде «делегатов»
Их-то наверняка, ибо они и в "Объектном Паскале", и в Дельфах есть. Как продукт вторичный, ФриПаскаль скорее неохотно поддержит чужую фигню, чем сделает по-своему что-то новое.

Сознаюсь/соглашусь: понятия не имею о планах на "замыкания", но какие-то (пока — внутренние) штуки, как-то связанные с функциональной парадигмой там появляются, так что со стороны реализации в компиляторе к "замыканиям" они приближаются (в основном, правда, это SSA и SSU оптимизации, причём SSU, как я понял, может и не появиться, а SSA как-то используется).

Я "делегатами" не пользовался, а вот по (не до конца понятным мне образом увязываемым с "делегатами" как сугубо объектно-ориентированная альтернатива) внутренним классам весьма скучаю.

(Reply to this) (Parent) (Thread)

>Их-то наверняка, ибо они и в «Объектном Паскале», и в Дельфах есть.
это где же в Delphi делегаты? впрочем, я считаю, что Delphi закончился на 7-й версии, дальше пошло какое-то пиздоблядство, которое ни ставить, ни использовать не надо.

>а вот по (не до конца понятным мне образом увязываемым с «делегатами» как
>сугубо объектно-ориентированная альтернатива) внутренним классам весьма
>скучаю.
лучше бы сделали одну простую вещь — защищённые/приватные объявления в модуле.

interface
type private TMyType;
type protected PMyType = ^TMyType;
implementation
type TMyType = ….;

с обычным смыслом protected/private. и да — возможностью объявлять имя в интерфейсе и описание в реализации. мне часто этого не хватало.

(Reply to this) (Parent) (Thread)

Я пользуюсь D2007. Она более готова к современным реалиям: в D7 неправильно работают объекты (хранящийся в стеке аналог класса), ужасная работа с памятью (медленно и глючно, естественно, в условиях большой нагрузки, которую, видимо, не особо отлаживали/предполагали в давние годы).

Часть этого можно исправить какими-то заплатками неофициальными, но поддержка всякой "Просеки" и т.п. даётся с ещё бОльшим трудом (для меня лично камень преткновения — управление памятью).

Мне не нравится среда разработки, но всё равно пользуюсь.

Вот так.

А консольный ФриПаскаль мне нравится больше (хотя я только Окнами пользуюсь), но Лазарь для графических интерфейсов не годится совершенно.

(Reply to this) (Parent) (Thread)

>в D7 неправильно работают объекты (хранящийся в стеке аналог класса)
??? O_O это, пардон, бредятина какая-то написана. class — это одно. object — совсем другое. class instance — третье. object instance — четвёртое. ниего не понял.

>жасная работа с памятью (медленно и глючно, естественно, в условиях
>большой нагрузки, которую, видимо, не особо отлаживали/предполагали в
>давние годы).
все давно привинтили fastmem заместо стандартного аллокатора (который дебильный, да). в следующих версиях даже борланды догадались и запихали fastmem в коробку. мне это удивительно, потому что обычно они пихают в коробку наиболее глючный и наименее юзабельный из всех возможных вариантов (FastNet, QuickReport, Rave Reports, Indy).

>Мне не нравится среда разработки
аналогично. потому использовалась только для рисования форм, остальной код делался в фаре. %-) впрочем, формы в Delphi ублюдские — где layout manager? завсегда приходилось накладывать поверх свои костыли.

>Лазарь для графических интерфейсов не годится совершенно.
O_O пуркуа? у меня отлично получалось, чем именно он не годится?

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

(Reply to this) (Parent) (Thread)

??? O_O это, пардон, бредятина какая-то написана
ЧЁД: http://community.freepascal.org:10000/docs-html/ref/refch6.html#x61-690006 (у объектов ключевое слово "object", а не "class")

все давно привинтили fastmem заместо стандартного аллокатора
В принципе да, но неофициально.

аналогично. потому использовалась только для рисования форм, остальной код делался в фаре. %-)
Близко к этому и у меня. Хотя в седьмой версии интерфейс и быстродействие получше обычно.

где layout manager?
Что это?

чем именно он не годится?
Свойств мало у каких-то стандартных классов, поддержка Дельф хромает (если бы какое-то время назад не было проблем с какими-то примитивными вещами, чуть ли не с полужирным шрифтом, то меня не волновала бы совместимость с Дельфами). Я опять посмотрю, наверное, скачаю, скажу. Правда, я собирался дождаться версии 1.0.

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

(Reply to this) (Parent) (Thread)

>у объектов ключевое слово «object», а не "class"
я в курсе, я ещё помню торжественное появление TP5.5. потому и озадачиваюсь — не бывает «хранящихся на стеке объектов», только экземпляры оных. и, кстати, что там работает неверно? по-моему, всё точно как в TP5.5.

>В принципе да, но неофициально.
с D8 или D10 официально.

>Что это?
в двух словах — «автораскладчик» контролов. который криво-криво и тупо-тупо, кряхтя и матерясь, можно сэмулировать кучей панелей и выставлением align: layout managers. нужен для нормального создания «резиновых» морд. align/anchors тут не катит, слишком бедный инструмент.

>войств мало у каких-то стандартных классов, поддержка Дельф хромает
Lazarus is *not* an 'open source Delphi clone'. So don't expect 100% compatibility.

>Яве, например, сборщик мусора не помогает (тормоза)
а это уже другая проблема. см. Oberon — и мусор собирает, и тормозов нет. и дальше BlackBox Component Builder, как очень навороченая RAD с инсталлятором в 5 мб, написаная на Component Pascal — наследнике Oberon.

(Reply to this) (Parent) (Thread)

и, кстати, что там работает неверно?
Исходники не пришлю, но изначально написанное на ФриПаскале в D7 вызывало глюк в компиляторе, в D2007 нормально компилировалось (даже если глюк в программе, в компиляторе он точно есть). Замена объектов на классы проблему решала. Но везде переделывать не хотелось.

с D8 или D10
Это определённо не D7…

layout managers
Да, вещь нужная. Да, её нет.

So don't expect 100% compatibility.
Как я и написал, после выбора Дельф для перехода на Лазаря эта поддержка необходима. Дельфы были выбраны два года назад, тогда Лазарь хромал (кажется, я даже полужирным шрифтом без извращений не мог на форме писать).

см. Oberon
Посмотрю. Но, похоже, больше смотреть мне надо на цепепе, где даже свойств в классах, по словам товарищей, нет: только в интерфейсах. Сейчас в процессе рассмотрения вакансии цепепешной (ради большего количества математики, а не ради цепепе).

(Reply to this) (Parent) (Thread)

>Замена объектов на классы проблему решала.
хм. объекты и классы — сильно разные вещи. подозреваю, что ошибка таки была в логике.

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

>Это определённо не D7…
а кто мешает в D7 fastmem всунуть? нигде не сказано, что «нельзя трогать аллокатор из генофонда».

>после выбора Дельф для перехода на Лазаря эта поддержка необходима
да, придётся поработать напильником. зато один раз. %-)

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

>Сейчас в процессе рассмотрения вакансии цепепешной
искренне сочуствую. злейшему врагу не пожелаю работать в цпп-проекте. плавали, знаем…

(Reply to this) (Parent) (Thread)

подозреваю, что ошибка таки была в логике.
1. Во ФриПаскале работало без намёков на проблемы.
2. Никакие ошибки в логике пользовательской программы не должны вызывать исключений в dll-ках компилятора.

а кто мешает в D7 fastmem всунуть? нигде не сказано, что «нельзя трогать аллокатор из генофонда».
Лень мешает и совместимость: нужно всем всовывать. Собирают мои тексты не у меня на машине. Вот переход на D2007 — понятно. А что-то курочить, когда у большинства и так работает — не поймут. И так с надстройками (TMSUnicode, ещё что-то) накладки происходят иногда.

да, придётся поработать напильником. зато один раз. %-)
Ненавижу ковыряться с собственным старым кодом. Я ж не так давно профессионально стал программировать, и тексты у меня весьма корявые.

злейшему врагу не пожелаю работать в цпп-проекте
Ну, я в текстах чужих на этом несовременном языке и так ковыряюсь постоянно. Дело за собственными текстами. Ява меня пугает больше, а цепепе — второй язык, после бейсика, который я изучал в школе, что-то на нём писал.

(Reply to this) (Parent) (Thread)

>1. Во ФриПаскале работало без намёков на проблемы.
это ещё не значит, что всё было правильно.

>2. Никакие ошибки в логике пользовательской программы не должны
>вызывать исключений в dll-ках компилятора.
мнэ… а зачем ты с собой эти DLL таскал и использовал? оно лицензией запрещено.

>Лень мешает и совместимость: нужно всем всовывать. Собирают мои тексты не
>у меня на машине.
ну и что? положил к себе в каталог, добавил в bpg — получилось. чем оно отличается от исходников, написаных лично тобой в этом случае? это не компоненты, это модуль, прописал в uses и поехало.

>Ненавижу ковыряться с собственным старым кодом.
хи. а заодно и отрефакторить по пути можно. всяко дело полезное. %-)

>Ява меня пугает больше
как раз жабка проще в плане синтаксиса. для цпп вообще компилятора не существует (вроде бы всё ещё нет; обломки, не реализующие стандарт ANSI, полноценными компиляторами называть нельзя), о чём дальше говорить-то?

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

(Reply to this) (Parent) (Thread)

мнэ… а зачем ты с собой эти DLL таскал и использовал?
Ой! А я просто кнопочку "компилировать" в среде разработки нажимаю, а мне пишут об исключении в DCC70.DLL. Это запрещено лицензией??

это не компоненты, это модуль, прописал в uses и поехало.
В тот момент оказалось, что в D2007 работает, а в D7 — нет. То, что дело именно в управлении памятью, скорее догадка.
О том, что реальные пацаны меняют управление памятью, я узнал существенно позже (переделывать проекты D2007 в D7 наверняка можно, но лень).

хи. а заодно и отрефакторить по пути можно. всяко дело полезное. %-)
Но что-то тоска берёт.

запутаешься одинаково
По-разному. К Яве-то у меня неприязнь. Её ещё преодолеть надо.

(Reply to this) (Parent) (Thread)

>А я просто кнопочку «компилировать» в среде разработки нажимаю
не нажимай. IDE — то ещё глючище, особенно если у тебя компонентов понаставлено. собирай при помощи dcc32.exe

>переделывать проекты D2007 в D7 наверняка можно, но лень
не надо там ничего переделывать. включил в проект fastmem, прописал во всех uses первым и всё. это все изменения.

>К Яве-то у меня неприязнь.
у меня тоже, хрен редьки не слаще, в общем-то.

(Reply to this) (Parent) (Thread)

не нажимай. IDE — то ещё глючище,
Что ж, хороший повод для обновления (правда, среда D2007 глючит в целом больше, но со сборкой проблем меньше).
Честно говоря, сомневаюсь, что dcc32.exe и dcc70.dll существенно отличаются в этом смысле.

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

(Reply to this) (Parent) (Thread)

>Честно говоря, сомневаюсь, что dcc32.exe и dcc70.dll существенно
>отличаются в этом смысле.
ещё как. среда падучая по жизни, и по абсолютно любой непредсказуемой причине. очень много к этому добавляют всякоразные компоненты, которые срут куда не попадя в памяти. вообще, категорически воспрещено юзать что-либо сверх Raize (и иногда TNT). а лучше и без них. и сервиспаки все накатить, натурально.

а в следущих версиях исправили как раз стабильность: падать стало стабильно чаще. %-)

(Reply to this) (Parent)

защищённые/приватные объявления в модуле.
Зачем?

(Reply to this) (Parent) (Thread)

interface

type private TMyOpaque;
type PMyOpaque = ^TMyOpaque;

type TMyOuterClass = class
 protected
  fData: PMyOpaque;
 ….
end;

implementation

type TMyOpaque = record
  …
end;

что даёт рабочую проверку типов, но невозможность «поковыряться» в TMyOpaque.

без такой фигни придётся переносить TMyOpaque в реализацию, делать fData простым указателем и потом без конца трахаться с приведениями. или показывать всем потроха TMyOpaque.

плюс — поскольку TMyOpaque приватная, класс-наследник из другого модуля может юзать указатель TMyOpaque/PMyOpaque, но всё равно внутрь никак не влезет.

модификатор protected нужен для расширяемых записей (вроде в D8 или D9 это появилось).

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent) (Thread)

ну, когда ты один код пишешь — вполне пофигу. а вот когда рядом пара обезьянок — лучше от них попрятать всё, что можно. если не спрятать — всенепременно полезут кривыми руками куда не положено.

(Reply to this) (Parent)

>почти во всех «свежих»
>компилируемых языках
из них «компилируемый» — только D. надо глянуть, как оно там сделано — я как-то плохо представляю эффективную реализацию замыканий в «нативном» компияторе. и вообще. так что ни у кого нет. %-)

зыж то, что компиляется в код какой-либо VM, «компилируемым» в моём понятии не является, пока этой VM нет в железе.

(Reply to this) (Parent)

в немерле есть замыкания

(Reply to this) (Parent) (Thread)

так оно ж функциональщина, куда оно без замыканий? %-)

(Reply to this) (Parent) (Thread)

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

(Reply to this) (Parent)

кстати, немерле (как и жаба) — не «компилируемые» языки. я (виноват, не пояснил) имелл в виду «компилируемые в нативный код».

(Reply to this) (Parent) (Thread)

компилируемость всегда
довольно условное понятие

(Reply to this) (Parent) (Thread)

потому и говорю, что виноват. надо было мне сразу термин определить.

(Reply to this) (Parent)

>jsshell.exe 1.js
37

Это со смыслом ответ, или так?

(Reply to this) (Parent) (Thread)

>Это со смыслом ответ, или так?
надо было до «42» дотянуть, не догадался. так что без смысла, просто цифры. %-)

(Reply to this) (Parent)