Java trick

[Timo Kinnunen]

If the motivation is optimization, you DONT want to
be making extra objects just so you cna jump through them.
Static dispatch is always faster than dynamic.

I'm not. The variables are static, they are never initialized and they are
only used for their type, so it's easy for an obfuscator to remove them.
The result should be the same bytecode as if I had used class names.

 

[Brian J. Sayatovic]

IMHO this behaviour is very consistent.
since a object can be null at any time and the method returns
an object of type CDummy the returned value is

null of type CDummy. therefore the static variable is accessable.

If that were the case than instanceof would return true in such cases,
but it does not. "null instanceof CDummy" returns false.

Regards,
Brian.

 

[Thomas G. Marshall]

P.Hill coughed up:

When you say the following, you have the usage of "type" and "class"
exactly reversed, as Joona said:

[note to all]

Since we've now put the primary issue of this thread to rest, I thought I'd
point something out I find both interesting and important to us all.

Because I've discovered that in my 8+ years of OO that one of the greatest
sources of arguments (primarily in usenet) seems to center *(often
unknowingly)* around what is meant by the following:

The type of {something}

....I posted a question in c.o concerning the terminology of type when
referring to poly-m objects.

The responses I got were, as you would expect, varied. Very heavy hitting
stuff in some cases, as is common among the purists in c.o, many of them
authors of multiple OO books.

I would suggest /anyone/ read through it here (it's short):

http://groups.google.com/groups?threadm=yMY2d.1156$9l1.252@trndny09

....[rip]...

 

[Chris Smith]

...I posted a question in c.o concerning the terminology of type when
referring to poly-m objects.

The responses I got were, as you would expect, varied. Very heavy hitting
stuff in some cases, as is common among the purists in c.o, many of them
authors of multiple OO books.

Interesting indeed. What I bring out of that, which modifies my general
understanding, is that there's a difference between what we mean by
"type" in the context of the Java language, and in a general OO context.
The two are related, and overlap considerably, but are not identical.
That makes this much more tricky to use in conversation. A good point
is made that objects can be said to have "type" in general OO theory,
despite the fact that a Java expression can never refer to them directly
and so that type never needs to be used in Java.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Thomas G. Marshall]

Chris Smith coughed up:

Interesting indeed. What I bring out of that, which modifies my
general understanding, is that there's a difference between what we
mean by "type" in the context of the Java language, and in a general
OO context.

Perhaps. Denizens in java land are prone to a java slant on OO terminology
and context, as are any language denizen. But I think that this mismatch in
notions is consistent across nearly all OOPL's, imho particularly statically
typed ones.

The two are related, and overlap considerably, but are
not identical. That makes this much more tricky to use in
conversation.

Oh criminey yes.

A good point is made that objects can be said to have
"type" in general OO theory, despite the fact that a Java expression
can never refer to them directly and so that type never needs to be
used in Java.

I'm not sure I read precisely that last point. Perhaps because everything
is "a pointer to". But for me to attempt a clarification is going to
bifurcate this thread beyond all reason .

That's the nature of this term. Many in usenet are so confident that they
have the strongest handle on this term that arguments ensue, not about the
definition of the term, but /caused/ by a misunderstanding of what the other
was trying to say /because/ of a difference in definitions.

 

[Gary Labowitz]

P.Hill coughed up:

When you say the following, you have the usage of "type" and "class"
exactly reversed, as Joona said:

[note to all]

Since we've now put the primary issue of this thread to rest, I thought I'd
point something out I find both interesting and important to us all.

Because I've discovered that in my 8+ years of OO that one of the greatest
sources of arguments (primarily in usenet) seems to center *(often
unknowingly)* around what is meant by the following:

The type of {something}

It depends on what the something is. Variables have type. Objects have
class.
Thus: dynamic polymorphism.

 

[Chris Smith]

It depends on what the something is. Variables have type. Objects have
class.
Thus: dynamic polymorphism.

Part of the point of the thread Thomas pointed to was exactly this:
that's a statement about Java, not about languages in general. Most
obviously, there are plenty of OO languages where variables don't have
type, and/or objects don't have class. But it runs deeper than that.
The rule in Java that objects are never variables simplifies things
considerably, but that's not true of the general case.

In other words, the terminology is a bit muddled, and that needs to be
acknowledged.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Thomas G. Marshall]

Gary Labowitz coughed up:

"Thomas G. Marshall"

P.Hill coughed up:

Thomas G. Marshall wrote:
When I teach students, I'm similarly faced with being extremely
careful in my wording.

When you say the following, you have the usage of "type" and "class"
exactly reversed, as Joona said:

[note to all]

Since we've now put the primary issue of this thread to rest, I
thought I'd point something out I find both interesting and
important to us all.

Because I've discovered that in my 8+ years of OO that one of the
greatest sources of arguments (primarily in usenet) seems to center
*(often unknowingly)* around what is meant by the following:

The type of {something}

It depends on what the something is.

Yes, of course. But the point is that {something} is /many/ things used
(right or wrong) conversationally. And even when the usage is technically
correct, it can /still/ mean something different.

Variables have type. Objects have
class.

That line met resistance in c.o. FWIW, ironically, in /this/ thread I was
credited with having said that, when I didn't.

Thus: dynamic polymorphism.

The larger point here is that I can use a differing set of terms than
"Objects have Class", and still end up with "Thus: dynamic polymorphism".