Агент расспределения

[NickProstoNick]

Согласен, частично я не прав.
Omh
Не чуть-чуть... а на много быстрее НО если использовать в такой конструкции

		Call doc.ReplaceItemValue( "field_1","123456789123456000f" )
Call doc.ReplaceItemValue( "field_2","123456789123456000f" )
Call doc.ReplaceItemValue( "field_3","123456789123456000f" )
Call doc.ReplaceItemValue( "field_4","123456789123456000f" )
Call doc.ReplaceItemValue( "field_5","123456789123456000f" )
....

но в такой конструкции не удобно... особенно если полей много... я пробовал с 100
Если же загонять в цикл - то

doc.field_1	=	"123456789123456000f"
doc.field_2	=	"123456789123456000f"
doc.field_3	=	"123456789123456000f"
...

работает немного быстрее

Но разница чувствуется при большом колличестве данных и не просто в итерациях а в контексте работы с документом

ну да ладно... разговор не об этом

 

[turumbay]

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

Ссылка скрыта от гостей

При этом на другой чаше весов лежит читабельность кода.
Так что не надо морочить людЯм головы.

P.S. Жалкие попытки спасти идею, оправдываясь, что имя поля может стать методом в следующей версии обречены на провал. Если заморачиваться на это, то нужно придумать что делать с именами библиотечных функций, переменных и прочими идентификаторами? ( Использовать ацкие префиксы для всех переменных в коде не предлагать )

P.S.S Попытки авторов сообщений в ветке принять этот пост как что-то личное также обречены. Ничего личного.

З.Ы. Модератору - прошу считать флеймом лишь на половину, ибо содержательная часть в посте присутствует

 

[Omh]

Что читабельнее - дело привычки.
Раньше мне казалось, что dot notation читабельнее, но, о чудо, прошло некоторое время как я его не юзаю, и мне кажется читабельнее способ через методы.

 

[lmike]

ежели посмотреть обычные классы - то присвоение пропертей таже ф-ция
зато в ф-ции есть возможность динамически подставлять имена
я могу на вход некой ф-ции передать два массивчика и там в цикле устанавливать соответст. значения
с пропертями - облом
типа:
Function SetValues(xFields As Variant, xValues As Variant)
i=0
forall f in xFields
Call doc.ReplaceItemValue(f,xValues(i))
i=i+1
end forall
end Function

 

[Omh]

Ещё удобно если например надо смигрировать пачку полей из одного дока в другой под разными именами.
Частенько в таких случаях использую конструкцию вида:

Dim Flds List as String
Flds("SourceFld1") = "DstFld1"
Flds("SourceFld2") = "DstFld2"
Flds("SourceFld3") = "DstFld3"
Flds("SourceFld4") = "DstFld4"
Forall x in Flds
Call DstDoc.ReplaceItemValue(x, SrcDoc.GetItemValue(Listtag(x)))
End Forall

А конструции вида

doc.~$FldName = ""

вообще порнуха.

 

[Yakov]

Однако, есть мнение, что оба варианта компилируются в одинаковый код.

И мнение это совершенно не верно.
Сравните хотя бы размер скомпилированного кода (NotesPeeker'ом, к примеру) для двух вариантов вроде

Public Sub doSomething(document As NotesDocument)
Print document.Form(0)
End Sub

и

Public Sub doSomething(document As NotesDocument)
Print document.GetItemValue("Form")(0)
End Sub

 

[turumbay]

to Omh, lmike:
В посте про расширенный синтаксис я ни слова не сказал за то, чтобы отказаться от использования getItemValue, replaceItemValue etc. Пост был направлен исключительно на развенчание мифа о вреде расширенного синтаксиса. Каждый волен выбирать - использовать его или нет. Но не надо необоснованно клеймить коллег и необоснованно насаждать собственную точку зрения.
Вопрос читаемости кода - это вопрос религии. Для меня строка doc.Title = "New Title" много проще, чем Call doc.ReplaceItemValue("Title" , "New Title") , для кого-то наоборот. Но речь идет о том, что первый вариант имеет право на жизнь и нет ни одной объективной причины не использовать его.

to Yakov:
Вы слишком категоричны. Судить о компилированном коде по его размеру - это круто. Вы не обратили внимание, что объектный код содержит, например, сам код в текстовом виде?
По мне, Стэн Роджерс( Stan Rogers ) - достаточно авторитеная фигура в мире LN, чтобы доверять его постам. Опровержений на ibm-ном форуме не последовало. А туда достаточно серьезные зубры заходят

 

[Omh]

turumbay
Так это...
В этой ветке вроде гнобления не замечалось.

 

[lmike]

turumbay
никто не упирал на ущербность и расширеного синтаксиса (ни я ни Omh)...
существует некое единообразие кода, дык вот...
ежели в большинстве случ. вызов Replace... более гибок - то зачем нарушать единообразие и пользоваться пропертями?!

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

 

[K-Fire]

Хехехе, холивар намечается

В кое-то веки я согласен со Стэном Роджерсом (кстати, кто это такой вообще? ), что расширенный синтаксис удобнее, читабельнее и меньше буков.

 

[Yakov]

turumbay
Если открыть вторую вкладку окошка свойства документа дизайна LS библиотеки, то можно обнаружить два интересных поля. Одно из них, $ScriptLib, действительно содержит текст библиотеки. Другое же, $ScriptLib_O, содержит скомпилированный байт-код. При скрытии дизайна БД первое поле удаляется, второе остается.
В байт-коде, помимо всего прочего, есть таблица символов, содержащая все встречающиеся в коде строки символов - идентификаторы (имена классов, переменных, процедур и т. п.), строковые константы и т. п. Эта таблица никак не зашифрована и видна в любом hex-редакторе и даже в том же окошке свойств элемента дизайна. (Так что, уважаемые разработчики, не храните разного рода пароли и регистрационные ключи в коде в открытом виде.)
Так вот, вернемся к моим примерам. В первом случае в таблице символов помимо всего прочего есть строчка "FORM", а во втором - строчки "GETITEMVALUE" и "Form" (строчки "FORM" нет).
Скорее всего, и исполняемый байт-код LS-машины для этих примеров отличается. В первом примере берется значение поля документа, во втором же вызывается метод NotesDocument.GetItemValue с аргументом "Form".
Таким образом, Stan Rogers, выразился не совсем точно. Он, наверняка, под словами "it compiles to the same code" имел ввиду "it compiles to the equivalent code", подразумевая идентичность результатов выполнения кода.
А "раз нет разницы, зачем платить больше?"
А какой способ "дороже" (выполняется дольше), могут сказать разработчики Lotus'а. Или эксперимент.
И, чтобы не отходить от темы холивара, скажу, что предпочитаю явный вызов методов GetItemValue/SetItemValue.

Вдогонку. Судя по следующему

Ссылка скрыта от гостей

:

As long as you aren't using it in an Execute statement, there shouldn't be (any difference will be handled at compile time, but since Execute statements are run-time interpreted, the "I've looked and looked and that's not a property, so it must be a field name" routine will probably slow things down).

, Stan Rogers не совсем понимает, что происходит при выполнении выражения Execute. Согласно справке, Execute function and statement сompiles and executes a text expression as a temporary module. То есть, в скорости исполения кода нет разницы между скомпилированным кодом библиотеки и скомпилированным же кодом из выражения Execute.
Авторитет Стэна сильно пошатнулся.

 

[lmike]

из того что вы привели не понятен ваш вывод...
он грит - что обработка замедлит процесс (имеется ввиду компиляция кода налету)

 

[Yakov]

Ага, точно. Я это немного погодя понял. Приношу свои извенения г-ну Роджерсу и беру свои слова, касаемые Execute statement, обратно.

 

[turumbay]

Скорее всего, и исполняемый байт-код LS-машины для этих примеров отличается. В первом примере берется значение поля документа, во втором же вызывается метод NotesDocument.GetItemValue с аргументом "Form".

Возьмите пятого клиента и убедитесь, что следующий код компилируеца и выполняеца:
Dim isLocked As Boolean
doc.Lock = isLocked
После чего убедитесь, что будучи скомпилированном в r5, этот код будет нормально выполняться в шестерке и выше.
После чего попробуйте скомпилировать код в шестерке или выше. Получите ошибку компиляции...

Никакого "берется значение поля документа" не существует. Существует вызов апишной функции для получения значения поля. В данном случае имеет место быть классическое раннее связывание - никакого перебора имен методов нет.

Таким образом, Stan Rogers, выразился не совсем точно. Он, наверняка, под словами "it compiles to the same code" имел ввиду "it compiles to the equivalent code", подразумевая идентичность результатов выполнения кода.

Вы все еще слишком категоричны. Слово "наверняка" треба использовать с чрезвычайной осторожностью
В посте идет речь не о результате выполнения, а именно о результате компиляции. Лексемы doc.Form = "New Form" и doc.ReplaceItemValue( "Form" , "New Form" ) при синтаксическом разборе превратится в объектное дерево, соответствующее вызову метода одного и того же апишного метода.

 

[Constantin A Chervonenko]

Лексемы doc.Form = "New Form" и doc.ReplaceItemValue( "Form" , "New Form" ) при синтаксическом разборе превратится в объектное дерево, соответствующее вызову метода одного и того же апишного метода.

нЭт..
В 1-м случае код будет, как минимум, таким: doc.ReplaceItemValue(UCase("Form"), "New Form")
Т.е.:
- код будет на 6 байт длиннее, и на 1мкс медленнее :blink:
- ну, не люблю я, когда мои любовно сконструированные имена полей без спроса кто-то корежит

 

[K-Fire]

нЭт..
В 1-м случае код будет, как минимум, таким: doc.ReplaceItemValue(UCase("Form"), "New Form")
Т.е.:
- код будет на 6 байт длиннее, и на 1мкс медленнее :blink:
- ну, не люблю я, когда мои любовно сконструированные имена полей без спроса кто-то корежит

Не хочу показаться занудным, но LS не всегда переводит имя поля в Uppercase. В частности из тыщ мест где у меня есть код doc.Form = "Blablabla" я наблюдал перевод имени поля в FORM достаточно редко. Точно не могу сказать, но есть подозрение что UCase делается если код выполняется на сервере, но не на клиенте.

 

[turumbay]

нЭт..
В 1-м случае код будет, как минимум, таким: doc.ReplaceItemValue(UCase("Form"), "New Form")

Да не будет никакого кода. И апперкейса не будет.(Либо будет в обоих вариантах. Хотя, скорее всего преобразование регистра производится внутри апишной функции) Если вспомнить, что движка LS - суть интерпретатор - то в обоих случаях объектный код приведет к вызову соответствующей функции из lib или dll или еще откуда(в зависимости от платформы). И объектный код в обоих случаях будет содержать ссылку на одну и ту же функцию. Он будет одинаковым. В момент времени выполнения нету разницы между нормальным и расширенным синтаксисом. Именно из-за этого я развил этот дурацкий флейм.
P.S. А байтов таки будет 7