Стандартный набор OCaml'щика ;)

Как большой спец - просветите, чем lazy не угодил?

И еще - а почему метод не может изменять состояние параметра? Иногда даже очень хочется и нужно это сделать. Другое дело, что он это должен делать только через методы этого параметра. Чтобы публичных данных не было. Но это везде в книжках написано. Если хотите поругать жабу за возможность публичных данных - ругайте. Наверное, можно было их запретить. Ну иногда так хочется соптимизировать...

2svu

lazy() не угодил способом избавления от побочного эффекта.

<<И еще - а почему метод не может изменять состояние параметра? Иногда даже очень хочется и нужно это сделать. Другое дело, что он это должен делать только через методы этого параметра. Чтобы публичных данных не было. Но это везде в книжках написано. Если хотите поругать жабу за возможность публичных данных - ругайте. Наверное, можно было их запретить. Ну иногда так хочется соптимизировать... >>

метод и изменяет состояние параметра.

>>> class E { public static void changeE() { s = "changed"; } public static String getE() { return s; } private static String s = "ok"; } } >>>

Вы хоть понимаете что такое static? Вы хоть понимаете, что если JavaBean по спецификации обязан быть сериализуем, то какие тут "статики"? Гослинга хоть читали? Признайтесь честно.

2svu ... кстати их, наверное, лучше было запретить

AC, не позорьтесь, нет здесь никакого побочного эффекта:

class E {

   public void changeE() {
      s = "changed";
   }
   public String getE() {
      return s;
   }
   private String s = "ok";
}

class Closed {

   private E e;
    
   public Closed() {
      e = new E();
   }
   public void setX(int XV) {
      e.changeE();
      x = XV;
   }
   public int getX() {
      return x;
   }
   private int x;
}

public class C {
public static void main(String[] Args) {
E e = new E();
System.out.println(e.getE());
Closed c = new Closed();
c.setX(101);
System.out.println(e.getE());
}
} 


Будет:
ok
ok

Позор!;-((

Ну, функциональщики, здорово вас тут NikS с последним примером умыл. Я тоже проверил. Действительно будет
ok
ok

здорово, мил человек!

а этот проверь:

class Demo { int i; static void m3(Demo d) { d.i++; System.out.println(d.i); } public static void main(String[] args) { Demo demo = new Demo(); System.out.println(demo.i); m3(demo); System.out.println(demo.i); } }

А это не JavaBean. NikS уже приводил тебе пример.

да причем тут JavaBeans!!!

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

если, уважаемый NikS, скажет всем своим подчиненным в конторе (которая пишет большые проекты): "Ребята, пишем код как следует и всех правил придерживаемся" - то все уних будет хорошо. До тех пор пока один возмет да и с оптимизирует написание публичными данными (согласен с svu - иногда очень охота по-быстрому), а второй заиспользует их как ему охота.

>> NikS уже приводил тебе пример.

На каждого мудреца довольно простоты

Еще раз спрашиваю - как изменяется состояние объекта класса C, который в данном случае является программой-"монитором".

class Demo // для JavaBean нужна еще сериализация, интроспекция & etc. { private int i; public void setI(int i) { this.i = i; } public int getI() { return i; } public void m3() { i++; System.out.println(i); } }

class C { public static void main(String[] args) { Demo demo = new Demo(); demo.setI(2); System.out.println(demo.getI()); demo.m3(); System.out.println(demo.getI()); } }

Столь одаренного и многоопытного Java-программиста, как этот yurban прошу проделать тоже самое со многими JavaBeans Demo, работающими в трэдах. (А то Луговский тут по поводу нитей на одном форуме распинался.)

Кстати, yurban, а Вы читали F&H? У меня появились сомнения.

>> До тех пор пока один возмет да и с оптимизирует
>> написание публичными данными

А можно и молотком по монитору врезать!

1. Вы 3 постулата ООП знаете?
2. Вы знаете четкое определение класса и объекта?

Тогда вопросы на вшивость:

1. Что кроме инстанции (экземпляра) класса в Java является объектом?
2. Могут ли в пакете быть сущности, отличные от интерфейсов+классов и других пакетов?

<Вы хоть понимаете что такое static?>

А вы думаете, нет?

<Вы хоть понимаете, что если JavaBean по спецификации обязан быть сериализуем, то какие тут "статики"? >

И что, мне требовать, чтобы все объекты были сериализуемы?
Ок, пусть будет так (к точкам с запятой, ради бога, не придирайтесь):
-------------------------------------------------------------------
class E {
 public E() {
   s = new String("ok");
 }
 public void changeE() {
   s = "changed";
 }
 public String getE() {
   return s;
 }
 private String s = null;
}

//Ecли можно использовать синглетоны.
class ESingleton {
  public static E e() {
    if(e_i == null) {
      e_i = new E();
    }
    return e_i;
  }
  private static E e_i = null;
}

class Closed {
 public Closed() {}
 public void setX(int XV) {
  ESingleton.e().changeE();
  x = XV;
 }
 public int getX() {
  return x;
 } 
 private int x;
}

class C {
 public static void main(String[] Args) {
   System.out.println(ESingleton.e().getE());
   Closed c = new Closed();
   c.setX(101);
   System.out.println(ESingleton.e().getE());
 }
}
----------------------------------------------------------------

<AC, не позорьтесь, нет здесь никакого побочного эффекта:>

Уважаемый автор монографий, хотелось бы, чтобы вы не делали идиотов ни из своих оппонентов, ни из себя самого. Что такое scope здесь все прекрасно знают.

<Будет:
ok
ok>

Естественно.

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

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

>> И что, мне требовать, чтобы все объекты были сериализуемы?

А как же, молодой человек! Все JavaBeans с интроспекцией обязаны быть сериализуемы. Только в _данном_ _конкретном_ случае я не использовал сериализацию. Если Вы это не поняли, то Вы вооще не знаете, что такое сериализация. Так что Вы просто плаваете в Java.

(Кстати, В entity EJB вОООще нельзя, чтобы класс ключа не был сериализуем. Если Вы этого не знаете, то Вам позор.)

>> поймите, побочный эффект _возможен_,

Плохому тианцору всегда кое-что мешает.

А вот некто Э.Р.Мулдашев утверждает, что число пи _возможно_ равно 3.(3)

А вот Гослинг возражает: Math.PI=3.1415926....

>> Еще можно попробовать запретить делать ошибки.

Если я напишу final public static diouble MyMath.PI=3.3333333

кто мне это запретит? РАН? ВАК? Комиссия по борьбе с лженаукой?

Просто дураков на приличных фирмах не держат. Вы пользуетесь операционкой написанной на императивном языке. Когда будет Linux написан на функциональном языке, тогда и будут Вас воспринимать всерьез!

2NikS

<<А можно и молотком по монитору врезать!>>

я думаю можно, только зачем?

<< 1. Вы 3 постулата ООП знаете? 2. Вы знаете четкое определение класса и объекта?

Тогда вопросы на вшивость:

1. Что кроме инстанции (экземпляра) класса в Java является объектом? 2. Могут ли в пакете быть сущности, отличные от интерфейсов+классов и других пакетов? >>

если Вы уже физически и вышли из возраста сопливого первокурсника, то фактически еще в нем пребываете.

Сколько по Вашему ошибок в больших проектов такого рода возникают?

Вы не ответили на мой вопрос:

"Могут ли в пакете быть сущности, отличные от интерфейсов+классов и других пакетов?"

Переходы на личности оставьте при себе. Я на них не отвечаю.

>> Сколько по Вашему ошибок в больших проектов такого рода возникают?

На WebSphere Studio или Sun ONE Studion? 0.

Вы не ответили на мой вопрос:

"Могут ли в пакете быть сущности, отличные от интерфейсов+классов и других пакетов?"

Переходы на личности оставьте при себе. Я на них не отвечаю.

>> Сколько по Вашему ошибок в больших проектов такого рода возникают?

На WebSphere Studio или Sun ONE Studion? 0.

Хе, так это не lazy надо переписывать, а весь класс.

Вторую мысль не понял. Если класс B меняет объект класса A через его, А , методы - чего ж тут за проблема?

Нет тут никаких проблем.

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

Ну хочется и форумным людям сказать, что мы элита, избранные, ибо знаем такую крутую экзотику как Caml, а Java - это попса.

2svu

<<Хе, так это не lazy надо переписывать, а весь класс.>>

да весь класс.

<<Вторую мысль не понял. Если класс B меняет объект класса A через его, А , методы - чего ж тут за проблема?>>

проблемы тут нет, все правильно.

проблема была в том, что NikS утверждал, что проблемы "побочного эффекта" (ПЭ) в Java нет. После предъявленного примера с ПЭ на Java, началось не пойми что и про JavaBeans и про ООП и пр.

2NikS

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

>> проблема была в том, что NikS утверждал, >> что проблемы "побочного эффекта" (ПЭ) в Java нет

Я не говорил что ПЭ в Java нет - наоборот я переработал Pascal пример из F&H. Я показал, что проблема ПЭ в Java сводится на нет. Что эта проблема ПЭ в императивных языках дутая. Что все крупные фирмы выбрали Java, а не Caml.

Я стал сомневаться в том, что Вы читали F&H и владеете лямбда-исчислением хотя бы в объеме курса М.Броя.

Кстати, Вы так и не ответили на мой вопрос про пакеты в Java.

Проблема это дутая для проектов порядка HelloWorld и чуть выше.

книгу F&H я не читал. Я читал Ф&Х (навсякий случай пишу, что это русский перевод).

на все Ваши вопросы про пакеты и пр. я ответил в постинге о Вашем возрасте.

<А как же, молодой человек! Все JavaBeans с интроспекцией обязаны быть сериализуемы.>

Ну и. В приведенном мной выше примере _некорректно_ меняется состояние объекта сериализуемого (гипотетически) класса E. Внимание, вопрос -- разрешено ли в JavaBeans использование синглетонов. Если да, то все ваши разговоры про _принципиальное_ отсутствие ПЭ в JavaBeans -- в пользу бедных.

<(Кстати, В entity EJB вОООще нельзя, чтобы класс ключа не был сериализуем. Если Вы этого не знаете,>

Да я только знаком с EJB и ими не пользуюсь -- у меня другая работа. А вы _досконально_ знаете JAI и Java3D? Если нет -- позор вам, вы не знаете Java.

<По иронии судьбы был я во Франции - никто там CAML особо не юзает, >

Мы наверное в разных Франциях были. Вот я здесь живу и работаю, и _хренова_ туча народу вокруг юзает именно что (o)caml.

<наряду со словом "ординатюр", хотя местные все равно говорили "компьютер>

И говорят все, что характерно, именно что "ordinateur". Ни разу за 3 года не встречал _француза_, говорящего "компьютер" -- он просто этого не выговорит, они искажают почти _все_ термины.

>> ... и чуть выше.

Да ну! Неужели мне платят за Hello, World? Или за "чуть выше"? А что это "чуть выше"?

>> на все Ваши вопросы про пакеты и пр. я ответил >> в постинге о Вашем возрасте.

Ничего не ответили. Ибо языком Java овладеть можно только путем написания именно крупных проектов. Я еще раз сказал - переход на личности я не воспринимаю.

singleton - бяка с точки зрения JavaBeans. Хотя могу ошибаться. (хотя не должен, все-таки brainbench MVP for Java 1:)

EJB - стандартная часть J2EE. Java3D/JAI - расширения. Ниже рангом. Можно не знать:)

Наверное, Вы живете в академической Франции...

<. Я показал, что проблема ПЭ в Java сводится на нет.>

Пока что вы ничего не показали. Вы показали _один_ _конкретный_ пример. Точно так же я могу написать
void f() {
char* mem = new char[1000];
delete[] mem;
}
и сказать, что проблема управления и утечек памяти в языках без сборки мусора сводится на нет. Действительно, достаточно всего-навсего освобождать выделенную память. А если кто этого не делает -- так можно и молотком по монитору, дураков в нормальных фирмах не держат.

>> А вы _досконально_ знаете JAI и Java3D

Вопрос в знании _основ_ Java. SCP получают за _основы_ Java 2. Кстати, по J3D и JAI нет еще теста на BrainBench, в то время как по J2D и J2EE я сдавал.

>> юзает именно что (o)caml

Я очень за них рад. А американы - те просто в восторге, что конкурент идет по ложному пути. (Кстати, в RH8.0, в отличие от глюкавого Mandrake 9.0 нет никаких камлов!)

Не надо путать выделение памяти и побочный эффект. Не надо софизмов.

Так оно и есть: AC - это бАААльшой ученый.

Я не сотрудник IBM, но в IBM центре под Ниццей сопровождают Linux, Java, DB2, WebSphere & etc.. И никаких CAMLов.

<Вопрос в знании _основ_ Java.>

Вот и скажите мне, как автор монографий, можно ли в коде, использующем JavaBeans, использовать синглетоны? Есть ли на них _явный_ запрет?

<Не надо путать выделение памяти и побочный эффект.>

Почему это путать? Это проблемы одного порядка, и решаются в императивных языках совершенно одинаковым образом -- методом грубой силы.
В том же C++ никто мне не мешает использовать те же smart pointers, и не использовать глобальных данных, статических членов и т.д. Значит ли, что в C++ нет проблемы управления памятью, и проблемы ПЭ?

>> можно ли в коде, использующем JavaBeans, использовать синглетоны?

Да, что и используется в проекте Eclipse, в котором работает сам E.Gamma. (Если Вы не читали GoF - то это Ваша проблема)

>> Это проблемы одного порядка, и решаются в >> императивных языках совершенно одинаковым образом -- >> методом грубой силы.

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

<Так оно и есть: AC - это бАААльшой ученый.>

А NikS, видимо -- инженеГр. Не вижу ничего зазорного в том, чтобы заниматься research.

<Я не сотрудник IBM, но в IBM центре под Ниццей сопровождают Linux, Java, DB2, WebSphere & etc..>

У меня иногда возникают сомнения в вашей адекватности. Совершенно естественно, что в _IBM_ центре под Ниццей сопровождают _именно_ технологии, на которые делает ставку _IBM_ -- то бишь Linux, Java, DB2, Websphere, etc, и только они. Скажем, дотнет там сопровождают?
И небольшой контрпримерчик -- в OTI (я надеюсь, это название вам что-нибудь говорит) пишут, и изрядно, аж на прологе.

В примере с new/delete есть натяжка. Вот если бы кто-то сказал - не используйте new, используйте supermupernew, для которого есть быстрый и эффективный сборщик мусора - и некая компания сделал бы это своим стандатром - тогда нужно было бы гнать тех, кто делает new. Так вот нормальная компания вполне может сделать javabeans своим стандартом. И это вполне внятный и непротиворечивый набор правил, который делает жизнь проще. Кстати, закрытие данных - это даже не JavaBeans, это из "общечеловеческих ценностей". И - главное - JavaBeans не решает _всех_ проблем языка, но указанную - о побочных эффектах - решает. С этим согласны, функциональщики. Дальще - орг. вопрос. Возможно, стОило вынести все эти вещи на уровень языка, а не правил. Но тут сложно.

Кстати, проблема синглетонов - это отдельный вопрос. Считать ли их частью состояния объекта? Не уверен. Да и при определении и использовании метода getInstance совсем не обязательно указывать, что он реально вызывает singleton - если с синхронизацией все в порядке, проблем не будет ни в каком случае (да, идеологически, да если считать это частью состояния...). В реальной жизни, при таком тормозном gc, как в жабе, singleton - ОЧЕНЬ важная вещь. Видел я jsp с custom tags - так там прогон gc занимал чуть не секунды!

>> А NikS, видимо -- инженеГр.

Догадливый, однако. Да я простой Java программер.

>> Не вижу ничего зазорного в том, чтобы заниматься research.

И получать соответственно.

>> И небольшой контрпримерчик -- в OTI (я надеюсь, это название вам >> что-нибудь говорит) пишут, и изрядно, аж на прологе.

Ну и что? И приходится им потом Smalltalk код переводить на Java. Мне же лучше.

<Да, что и используется в проекте Eclipse, в котором работает сам E.Gamma. >

Ну, тогда вообще о чем речь. Что вы тут тогда нам втирали, что де, если использовать JavaBeans, то проблема ПЭ сходит на нет? Приведенный мной выше пример с синглетоном убедительно показывает, что это не так.

<(Если Вы не читали GoF - то это Ваша проблема) >

Читал, читал -- на редкость скучная книга. Вам уже предлагалось -- не считайте своих оппонентов идиотами, вы выглядите глуповато.

<Ну, большому ученому виднее. >

Да не вопрос.

<Тем более продемонстрировшему нам столь высокую грамотность при создании Java кода. >

Знаете, уж лучше в коде, с листа вгонявшемся в форму, пропустить int, чем, с позволения сказать, нести здесь такую чушь, какую несете вы.

Да нету в сингельтонах никакой проблемы. E.Gamma показал что нету. Надоело E.Gamma заниматься research - вот и отвалил в IBM.

А что касается правил - то их определяют Eclipse/WSAD или SunONE Studio. Зачем ломать язык - только ради высоколобых ресечеров, практического толку от которых (как пишет Ален Голуб), как от козла молока?

<Вот если бы кто-то сказал - не используйте new, используйте supermupernew, для которого есть быстрый и эффективный сборщик мусора >

Давно есть самые разнообразные смарт-пойнтеры (смотрите boost). Давно есть сборщики мусора для C++. А проблема управления памятью -- есть.

<но указанную - о побочных эффектах - решает. >

Да не решает же!!! Показано же, как именно не решает -- состояние объекта можно изменить через синглетон.

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

Где это такой пример Вы откопали? Сами придумали?

>> Читал, читал -- на редкость скучная книга

Напишите свою. Только про int не забудьте.

>> уж лучше в коде, с листа вгонявшемся в форму, пропустить int, >> чем, с позволения сказать, нести здесь такую чушь, какую несете вы

Да ну?

<Да я простой Java программер. >
Тогда и не суйтесь в калашный ряд.

<И получать соответственно. >
Соответственно, очень неплохо.

>> состояние объекта можно изменить через синглетон.

Боюсь, что Вы не знаете, что такое сингелтон. Ту безграмотную чушь, которую Вы написали назвать сингелтоном (по E.Gamma) нельзя.

Эх, обидно, про smartpointers забыл. Все либо С, либо java - на плюсах давно не работал. Да, в языке С++ проблема есть. В том "над-языке", который выбирает для себя контора, делающая проект со smartpointers - проблем нет. В реальной жизни для проекта выбирают не столько язык, сколько framework (купленный или свой). Голый язык интересен только академикам. И в С++ можно сделать framework без проблем с памятью. И в жаба - без побочных эффектов.

Да, я посмотрел спеки бинзов. Там нет про синглетоны (не нашел). Но, мне кажется, они не соответствую духу... И - главное - это не часть состояния объекта. Это часть состояния класса. Разница все-таки есть...

>>><Да я простой Java программер. > >>> Тогда и не суйтесь в калашный ряд.

Куда там Java программеру до теоретика, который даже "singelton" без ошибок написать не может.

>> <И получать соответственно. > >> Соответственно, очень неплохо.

Эти байки оставьте для первокурсников.

Кстати, признаю свою ошибку. Нет в JavaBeans классического сингелтона. Просмотрел сейчас сорсы Eclipse. (Они доступны.) В JavaBeans шаблон гарантирует создание лишь единственного экземпляра внутри класса. Статика запрещена. Да я ошибся. Но и теория высоколобого AC рушится.

Да, кстати, AC имел в виду классический singleton типа:

class Singleton { public: static Singleton* Instance(); protected: Singleton(); private: static Singleton* _instance; };

Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance () { if (_instance == 0) { _instance = new Singleton; } return _instance; }

Естественно, в Java это не практикуется. Там есть анонимные классы, гарантирующие создание единственного экземпляра объекта.

Если AC напишет нам еще и анонимный класс, то тогда все - "три раза КУ!" верблюжатникам!;)))

<Где это такой пример Вы откопали?>

В сообщении 18:42:21.027.

<Сами придумали? >

Именно. А что, чем не пример? Опять демагогией занимаетесь?

<Напишите свою.>
Desing Patterns меня не интересуют. А в той области, что меня интересует, пока рановато. Это ж не монографии по Джаве писать:)

<Да ну?>

Ну да!

... Ряды сторонников Java вновь сомкнулись над телом несчастного singleton и упрочили оборону от нападок диких функциональщиков ...:)

>> Desing Patterns меня не интересуют.

Правильна! В Design Patterns думать нада! А AC даже класс типа "синглелтона" без ошибок написать не может.

Вы хоть что такое анонимные классы в Java разумеете? Или ликбез для титиретиков нужен? Если Гослинг для Вас слишком труден, то мою книжку почитайте - там это описано.

В Java есть anonymous inner classes. Нет там никаких singletons. Разве только, что AC напишет (с ошибками).

Viva la Java! ;-)