Важно

  •  

Saturday, September 01, 2012

Debka: ארה''ב לא תספק לישראל נשק ומטריה צבאית, גם לא נגד טילים, באם תתקוף את איראן (Hebrew, Russian)

ארה''ב לא תספק לישראל נשק ומטריה צבאית, גם לא נגד טילים, באם תתקוף את איראן

ביצע נשיא רוסיה ולדימיר פוטין מהלך כפול של ניתוק הקשרים הצבאיים הרוסיים עם איראן, ועם סוריה. מה שפוטין עשה עם טהרן ודמשק, אובמה עשה עם ירושלים.
...
ממשל אובמה וממשל פוטין הניחו את היסודות להסכם המתגבש ביניהם על הגרעין האיראני ועל סוריה, כאשר הם מנטרלים את הפוטנציאל הצבאי האיראני, הישראלי והסורי. זהו צעד ראשון לקראת השגת הסכם אמריקני-רוסי על הגרעין האיראני.
...
אם פוטין נטרל את איראן וסוריה, על ממשל אובמה לנטרל את ישראל, ולהביא לידי כך שישראל לא תתקוף את התוכנית הגרעינית האיראנית.
...
לפי שעון הלוי, יש לנו עוד 8 שבועות, כדי לקבל את התשובה על שאלה זו. וגם עוד 8 שבועות, לנתניהו וברק, לחיות תחת ההתקפה ללא תקדים של נשיא ארצות הברית באראק אובמה עליהם.

http://debka.co.il/article/22323/ארה-ב-לא-תספק-לישראל-נשק-ומטריה-צבאית-גם-לא-נגד-טילים-באם-תתקוף-את-איראן

Краткий перевод: США не предоставят Израилю военный зонтик в случае нападения на Иран. Россия прекращает военные поставки Сирии и Ирану. Россия и США сделали первый шаг к подписанию договора о ядерной программе Ирана. У Израиля осталось около 8 недель, чтобы принять решение об атаке.

Число безработных в еврозоне е является рекордным с 1995 года

Форматирование моё.

Число оставшихся без работы граждан еврозоны в июле 2012 года превысило 18 миллионов человек, а общий уровень безработицы составил 11,3 процента. Об этом говорится в официальном пресс-релизе Eurostat. Для сравнения, в июле 2011 года безработица в еврозоне составила 10,1 процента.

Текущий уровень безработицы в еврозоне является рекордным за все время наблюдений, то есть с 1995 года. Предыдущий рекорд в 11,2 процента был установлен в июне текущего года.

Ниже есть продолжение.

По сравнению с июнем число безработных в 17 странах зоны евро в июле 2012 года выросло на 88 тысяч человек. Самый высокий уровень безработицы был зафиксирован в Испании (25,1%) и Греции (23,1%). Наиболее низкие показатели безработицы оказались в Австрии (4,5%), Нидерландах (5,3), а также в Германии и Люксембурге (5,5%).

В 27 государствах, входящих в Евросоюз, число безработных в июле 2012-го достигло 25,254 миллиона человек, а уровень безработицы составил 10,4 процента. Годом ранее этот показатель находился на отметке в 9,6 процента.

В июле Международная организация труда опубликовала исследование, из которого следует, что если власти еврозоны не изменят экономическую политику, региону грозит резкий рост безработицы - до 22 миллионов человек.
http://cursorinfo.co.il/news/busines/2012/09/01/bezr/

צחי הנגבי על סיכויי תקיפה ישראלית באיראן (Hebrew, Russian)



Цахи hа-Негби, бывший глава комиссии по иностранным делам и обороне, заявил сегодня, что последние события дают Израилю дополнительную легитимацию для удара по Ирану. Речь идёт о последнем отчёте МАГАТЭ и о высказываниях иранских лидеров против Израиля. hа-Негби сказал, что

Угроза США по атаке Ирана должна быть заслуживающей доверия (אמינה). Иран пренебрегает (מצפצפים) этой угрозой...Если американцы не решатся, у нас не будет иного выхода. Израильская угрозя нападения не надуманна (לא איום מופרך).

Игорь Ашманов о новостных вбросах (11.05.2012)

Демура: Белые устали кормить чёрных

Демура: Германия покинет еврозону первой

A New Vision of Object-Oriented Programming (English)

Extract from the article (formatting is mine).
See also Mixin and treats.

...So the first new concept we introduce is roles. Whereas objects capture what objects are, roles capture collections of behaviors that are about what objects do...

There is more below.
Ниже есть продолжение.


The interactions that weave their way through the roles are also not new to programming: we call them algorithms.... What's interesting is that we consciously weave the algorithms through the roles. It is as if we had broken down the algorithm using good old procedural decomposition and broken the lines of decomposition along role boundaries. We do the same thing in old-fashioned object modeling, except that we break the lines of procedural decomposition (methods) along the lines of object boundaries.

Unfortunately, object boundaries already mean something else: they are loci of encapsulated domain knowledge, of the data. There is little that suggests that the stepwise refinement of an algorithm into cognitive chunks should match the demarcations set by the data model. Old-fashioned object orientation forced us to use the same mechanism for both demarcations, and this mechanism was called a class. One or the other of the demarcating mechanisms is likely to win out. If the algorithmic decomposition wins out, we end up with algorithmic fragments landing in one object but needing to talk to another, and coupling metrics suffer. If the data decomposition wins out, we end up slicing out just those parts of the algorithm that are pertinent to the topic of the object to which they are assigned, and we end up with very small incohesive methods. Old-fashioned object orientation explicitly encouraged the creation of such fine-grain methods, for example, a typical Smalltalk method is three statements long.

...It is almost a literal expansion from the Use Case. That makes it more understandable than if the logic is spread over many class boundaries that are arbitrary with respect to the natural organization of the logic—as found in the end user mental model...

...Both the roles and classes live in the end user's head. The two are fused at run time into a single object. Since objects come from classes in most programming languages, we have to make it appear as though the domain classes can support the business functions... At compile time programmers must face the end user's models both of Use Case scenarios and the entities they operate on. We want to help the programmer capture those models separately in two different programming constructs, honoring the dichotomy in the end user's head. We usually think of classes as the natural place to collect such behaviors or algorithms together. But we must also support the seeming paradox that each of these compile-time concepts co-exists with the other at run time in a single thing called the object.

...an object of a class supports not only the member functions of its class, but also can execute the member functions of the role it is playing at any given time as though they were its own. That is, we want to inject the roles' logic into the objects so that they are as much part of the object as the methods that the object receives from its class at instantiation time...we set things up so each object has all possible logic at compile time to support whatever role it might be asked to play. However, if we are smart enough to inject just enough logic into each object at run time, just as it is needed to support its appearance in a given role, we can do that, too.
http://www.artima.com/articles/dci_vision.html

Mixin and treats (English)

Formatting is mine.

Mixins are synonymous with abstract base classes. Inheriting from a mixin is not a form of specialization but is rather a means of collecting functionality. A class or object may "inherit" most or all of its functionality from one or more mixins, therefore mixins can be thought of as a mechanism of multiple inheritance...

...Mixins encourage code reuse and avoid well-known pathologies associated with multiple inheritance. However, mixins introduce their own set of compromises...

...When a class includes a mixin, the class...includes, rather than inherits, all the mixin's attributes (fields, properties) and methods. They become part of the class during compilation.
http://en.wikipedia.org/wiki/Mixin

There is more below.
Ниже есть продолжение.


With mixins the class definition defines only the attributes and parameters associated with that class; methods are left to be defined elsewhere, as in Flavors and CLOS, and are organized in "generic functions". These generic functions are functions that are defined in multiple cases (methods) by type dispatch and method combinations.

CLOS and Flavors allows mixin methods to add behavior to existing methods: :before and :after daemons, whoppers and wrappers in Flavors. CLOS added :around methods and the ability to call shadowed methods via CALL-NEXT-METHOD. So, for example, a stream-lock-mixin can add locking around existing methods of a stream class. In Flavors one would write a wrapper or a whopper and in CLOS one would use an :around method. Both CLOS and Flavors allow the computed reuse via method combinations. :before, :after and :around methods are a feature of the standard method combination. Other method combinations are provided.

...Some languages like ECMAScript (commonly referred to as JavaScript) do not support mixins on the language level, but can easily mimic them by copying methods from one object to another at runtime, thereby "borrowing" the mixin's methods. Note that this is also possible with statically typed languages, but it requires constructing a new object with the extended set of methods...

...Some of the functionality of mixins is provided by interfaces in popular languages like Java and C#. However, an interface only specifies what the class must support and cannot provide an implementation. Another class, providing an implementation and dependent with the interface, is needed for refactoring common behavior into a single place.

Interfaces combined with aspect-oriented programming can produce full fledged mixins in languages that support such features, such as C# or Java. Additionally, through the use of the marker interface pattern, generic programming, and extension methods, C# 3.0 has the ability to mimic mixins.
http://en.wikipedia.org/wiki/Mixin


A little sample in Scala Language:


class Point2D(xc: Int, yc: Int) {
   val x = xc;
   val y = yc;
   override def toString() =
  "x = " + x + ", y = " + y;
 }
 class ColoredPoint2D(u: Int, v: Int, c: String)
   extends Point2D(u, v) {
   var color = c;
   def setColor(newCol: String): Unit = color = newCol;
   override def toString() =
  super.toString() + ", col = " + color;
 }
 class Point3D(xc: Int, yc: Int, zc: Int)
   extends Point2D(xc, yc) {
   val z = zc;
   override def toString() =
  super.toString() + ", z = " + z;
 }
 class ColoredPoint3D(xc: Int, yc: Int, zc: Int, col: String)
  extends Point3D(xc, yc, zc)
  with ColoredPoint2D(xc, yc, col);

And
new ColoredPoint3D(1, 2, 3, "blue").toString() 
would return
"x = 1, y = 2, z = 3, col = blue". 
http://c2.com/cgi/wiki?MixIn

Mixin can be viewed as partial realization of multiple inheritance. In the programming languages that supports multiple inheritance, mixin can be easily emulated. For example, in C++ template can be used for adding operator given operator «==»:

template  struct AddNoEq {
    virtual bool operator==(const T &cmp) const = 0;
    bool operator!=(const T &cmp) const {
        return !static_cast(this)->operator== (cmp);
    }
 };

#include 
 
 struct Complex : public AddNoEq {
    Complex(int re, int im): re_(re), im_(im) { }
    
    virtual bool operator==(const Complex& cmp) const {
        return cmp.re_ == this->re_ && cmp.im_ == this->im_;
    }
    // ...
 private:
    int re_, im_;
 };

 int main()
 {
    Complex a(1, 2), b(2, 3);
 
     if (a != b)
        std::cout << "That's ok" << std::endl;
     
     return 0;
 }
http://ru.wikipedia.org/wiki/Примесь_(программирование)