Здравствуйте, kan_izh, Вы писали:

>> ANS>То есть добавление переменной в объект не скажется на других
>> объектах этого класса? Типа прототипов?
>>
>> Типа того, что т.н. instance variable первый раз инстанцируется в
>> объекте при первом обращении к ней. Нет обращения -- нет и переменной
>> (атрибута). Вот для примера:
_>Не понял. Вроде многие известные скриптовые языки позволяют это, тот же перл, яваскрипт. Менять объекты — ничего
_>интересного, интереснее — классы. В яваскрипте для этого есть prototype. А что такого в ruby?

Есть.

_>Классический пример. В javascript есть стандартный класс String, у которого не предусмотрен метод trim. Можно легко
_>добавить:
_>

_>String.prototype.trim = function()
_>{
_>    return this.replace(/^\s+/,'').replace(/\s+$/, '')
_>}

_>WScript.echo('['+("   adf   ".trim())+']')
_>

'mama'.booo #=> undefined method 'booo' for "mama":String

class String
    def booo
        print "boo!"
    end
end

'mama'.booo #напечатает 'boo!'

Здравствуйте, Petrovich_Alex, Вы писали:

P_A>значит можно поменять классы в java.lang.*?
нет, можно поменять лишь часть, причем в определенных пакетах.

P_A>А как поведет себя jre, если я уберу пару классов в java.lang.*?
убрать нельзя, только подменить

P_A>как я понимаю, она не пройдет кучу тестов в sun.
есть множество jre, в которых большая часть функциональности не реализована. JRE не обязательно должна реализовывать все фичи/классы J2SE. В ней главное — интерпретарор/компилятор байт-кода, чтобы соответсвовал спецификациям.
P_A>развитие jre идет по плану. что-бы поменять, что-то надо пройти определенных процесс. а идеология (и защищенность и еще кучу свойств) java стоится на монолитности библиотеки.
Просьба не смешивать платформу, виртуальную машину и язык

Здравствуйте, -=[x]=-, Вы писали:

X>нет, можно поменять лишь часть, причем в определенных пакетах.
X>убрать нельзя, только подменить
это все полумеры, которые практически не доступны в программировании.
и 95% этим некогда не пользовались...

X>есть множество jre...
какие?

X>в которых большая часть функциональности не реализована....
какая часть?

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

X>JRE не обязательно должна реализовывать все фичи/классы J2SE.
да ну.... как это не обязана? об этом где можно почитать?

X>В ней главное — интерпретарор/компилятор байт-кода, чтобы соответсвовал спецификациям.
это спецификация на vm...
а есть спецификация на язык.
и есть тесты в sun. на которых прогоняют машины, классы и т.д.

X>Просьба не смешивать платформу, виртуальную машину и язык

а в java это ну очень сильно смешано...

Зверёк Харьковский wrote:

> prototype. А что такого в ruby?
>
> Есть.
>
> _>Классический пример. В javascript есть стандартный класс String, у
> которого не предусмотрен метод trim. Можно легко
> _>добавить:

Короче, для скриптовых языков это вполне нормальная ситуация. А вот с компилируемыми всё гораздо хуже.

Здравствуйте, Petrovich_Alex, Вы писали:

P_A>это все полумеры, которые практически не доступны в программировании.
P_A>и 95% этим некогда не пользовались...
Как и тем, о чем тема этого топика

X>>есть множество jre...
P_A>какие?
P_A>и что на них работуют все приложения..?
P_A>я вот никак в дебаине (на его реализации Java) не могу запустить несколько приложений... это что, "переносимость"?
Например, gcj, который в дебиане. реализация от сана является референсной... Которая вполне переносима, как в прочем и некоторые другие (например от ibm).

X>>JRE не обязательно должна реализовывать все фичи/классы J2SE.
P_A>да ну.... как это не обязана? об этом где можно почитать?


X>>В ней главное — интерпретарор/компилятор байт-кода, чтобы соответсвовал спецификациям.
P_A>это спецификация на vm...
P_A>а есть спецификация на язык.
P_A>и есть тесты в sun. на которых прогоняют машины, классы и т.д.
а есть спецификации на J2SE, J2EE, J2ME, RtJava. Все перечисленное — платформы. JRE сама по себе не платформа.

X>>Просьба не смешивать платформу, виртуальную машину и язык
P_A>а в java это ну очень сильно смешано...
Не согласен.

Здравствуйте, -=[x]=-, Вы писали:
P_A>>и 95% этим некогда не пользовались...
X>Как и тем, о чем тема этого топика

Не пользовались, потому что нет средств. А как уже мне показали, что если есть средства (возможности), то этим пользуются как например в руби

Автор: eao197
Дата: 23.03.06

.

а если возможности нет, то ее или не используют, или извращаются... а как показала практика, в Java такой возможности нет.

X>>>JRE не обязательно должна реализовывать все фичи/классы J2SE.
offtop: "да ну.... как это не обязана? об этом где можно почитать?"
это уже будет не jre, а что нибудь другое, и под другим названием


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

и вообще, прочему есть разделение между библиотекой и прикладной программой?

Здравствуйте, Petrovich_Alex, Вы писали:

P_A>а если возможности нет, то ее или не используют, или извращаются... а как показала практика, в Java такой возможности нет.

В java можно поменить базовую библиотеку используя -Xbootclasspath. (Правда, врядли получится удалить или несовместимо изменить такие фундаментальные классы, как java.lang.Object, java.lang.String, java.lang.Class)

X>>>>JRE не обязательно должна реализовывать все фичи/классы J2SE.
P_A>offtop: "да ну.... как это не обязана? об этом где можно почитать?"
P_A>это уже будет не jre, а что нибудь другое, и под другим названием

Полагаю, речь идет об optional packages, которые можно скачать и использовать, а можно и не скачивать, если не нужно. Или скачать, если нужно, у другого поставщика.

P_A>вопросы
P_A>почему считается, что основу ("библиотеку", еще что нибудь) менять из прикладной программы трудно и не нужно?
P_A>(считается что прикладные программисты хуже системных?).
P_A>пуcть прикладная программа использует только то, что ей дает библиотека?

Во-первых, код сложно сопровождать, если он полагается на "нестандартное" поведение базовых библиотек.

И во-вторых, при возможности изменять базовые библиотеки приходится решать указанную тобой же проблему:

Как будет распространяться программы, которые работают на разных "базовых библиотеках"?

Как правило, базовые библиотеки разрабатываются (и любые библиотеки должны разрабатываться) таким образом, чтобы их можно было расширять, а не модифицировать (Open-Close Principle). И как правило, для решения задач, которые можно было бы решить изменениями в базовой библиотеке; можно найти более простое и безопасное решение.

Здравствуйте, dshe, Вы писали:

D>Как правило, базовые библиотеки разрабатываются (и любые библиотеки должны разрабатываться) таким образом, чтобы их можно было расширять, а не модифицировать (Open-Close Principle).

Однако ж, в этой конфе постоянно пишут, что спроектировать расширяемую во все стороны архитектуру не возможно.

D>И как правило, для решения задач, которые можно было бы решить изменениями в базовой библиотеке; можно найти более простое и безопасное решение.

Например?

Здравствуйте, dshe, Вы писали:

D>В java можно поменить базовую библиотеку используя -Xbootclasspath. (Правда, врядли получится удалить или несовместимо изменить такие фундаментальные классы, как java.lang.Object, java.lang.String, java.lang.Class)

Можно, но это "грабли"....

D>Полагаю, речь идет об optional packages, которые можно скачать и использовать, а можно и не скачивать, если не нужно. Или скачать, если нужно, у другого поставщика.

D>Во-первых, код сложно сопровождать, если он полагается на "нестандартное" поведение базовых библиотек.

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


D>И во-вторых, при возможности изменять базовые библиотеки приходится решать указанную тобой же проблему:
D>

Как будет распространяться программы, которые работают на разных "базовых библиотеках"?

А что, так уж трудно придумать?
Если бы у тебя была такая задача, то как бы ты сделал?

D>Как правило, базовые библиотеки разрабатываются (и любые библиотеки должны разрабатываться) таким образом, чтобы их можно было расширять, а не модифицировать (Open-Close Principle).

заносим в копилку...

А почему первая ссылка на гугле по "Open-Close Principle" идет на описание принципа по отношению к С++ (статическому языку)?
Open-Close Principle on google


D>чтобы их можно было расширять, а не модифицировать...

а если мне не надо расширять, а надо убрать кучу вещей которые мне не нужны...

D>И как правило, для решения задач, которые можно было бы решить изменениями в базовой библиотеке; можно найти более простое и безопасное решение.

Если для меня самое безопасное решение — изменить что нибудь в базовой библиотеки?
Я беру и изменяю. И у меня есть тесты системы, и тесты программы.
У меня стирается грань между кодом библиотеки и прикладным кодом.

Я не хочу воспринивать код библиотека как неизменяемый.

Базовый код делают несколько человек, а используют несколько тысяч...
И как писали в какой то книге про триз:
"Кучка академиков наук не смогла соперничать с творчеством народа" ....