Question about compile-time legality rules for cast conversion

Question

Hi, In the rules which explain compile-time legality for cast conversion, it is often mentioned the following scenario in the cast conversion of a compile-time type S to a compile-time type T:
if S is a class type then:
if T is a class type then either |S| <: |T| or |T| <: |S| or a compile time error occurs. Furthermore, if there exist a supertype X of T and a supertype Y of S such that X and Y are provably distinct parameterized types and that the erasures of X and Y are the same, a compile-time error occurs.
As regards the quote in bold, I imagine the following scenario:
1) S <: T and extends Y
2) Y<T1...Tn>
3) X<T1..Tn>
4) T extends X
Does the above represents a supertype X of T and a supertype Y of S such that X and Y are provenly distinct parameterized types? If that holds, what does it mean that the erasure of X and Y is the same?

Answer 1

Declarative programing has all but gone the way of
the doe doe because...
1: It is not flexible (It is extremely difficult to
change a complex system in a predetermined way)isn't this the "expert system" model?
2: It lengthens the development cycle (see item 1)
3: It normally forces the developer to add many
things to there code to get things to work, that have
nothing to do with the intent of the code.more things? the declarations or the declaration processing?
In its defense (I like a declarative model but, do
not like being forced into one)...not advocating a forced change in Java
1: It increases code safety.
2: It can shorten the development cycle, in certain
circumstances (especially if it is not overused),
because it can greatly increase the readability of
code.
3: It follows many best practices (although this is
also possible in a Non-Declarative model).as for best practices what I'd like to see are declarative design patterns, Adapter, Singleton, Factory, Delegate, Strategy, Interpreter, Proxy, Visitor
too often the design intent is lost in an implementation or design details can only be deduced by class/field/method names, comments, and accompanying docs
So, if everyone had unlimited time, and an unlimited
budget, yes declaritive is the way to go. Since that
is not the case, we filtered out 99% of what it gave
us, made sure the stuff that was getting in the way
was removed, and what do you have???
You guessed it OOA&D.
Now having said that should we be more declarative? I
think so, but I will tell you now, REQUIRING
declarative elements in code is a sure fire way to
get the majority of development groups to drop the
language (and I think Java as it stands currently CAN
be declarative, so if you have one of those unlimited
budgets, go for it!).no need to require it
I believe given good (reusable) declarative options, on top of OOP, will become the chosen approach
reusable design declarations would lessen overall cost and increase readability