Re: writeObject signature

From: Chris Smith (cdsmith_at_twu.net)
Date: 06/11/04 

Date: Thu, 10 Jun 2004 16:17:06 -0600

Michael Rauscher wrote:
> Serializable doesn't declare any methods. Therefore either the developer
> or the compiler must do a cast to Object.

That's a fairly confusing way to put things, though. The word "cast" in
Java refers to a syntax for type conversion -- namely, placing the
target type name in parentheses prior to an expression. The compiler
doesn't generate source code, so it can't "do a cast".

If you would prefer to talk bytecode compiler implementation, then
neither does it insert a 'checkcast' bytecode instruction. If you
insist on talking JIT compiler implementation, there's *still* no extra
step in generated code to express an implicit type conversion. The
compiler simply indexes into the function pointer table for the object,
*knowing* that it's a valid instance of Object.

There are implicit widening conversions in Java, which are sometimes
confusingly referred to as "upcasts". Nevertheless, unless you choose
to do so unnecessarily, these conversions don't require a cast.
Besides, this isn't a widening conversion anyway. There's never a wider
type involved in this expression.

> Between the interface Serializable and the class Object there's no
> relation. In the first example, it would be wrong (or bad design) to
> send a getClass message to "a" at design time, because "a" is
> Serializable and Serializable doesn't declare such a method.

And this pretty much sums up why you shouldn't become obsessed with UML
for making design decisions for you. Here you're confusing a quirk of
the UML modelling format with justification for API design. Let me put
this simply: there's absolutely no good reason to avoid calling methods
of java.lang.Object via an interface type. When you start considering
that, it's a good sign that you're letting your desire to do "clean"
design interfere with your ability to use the language you're working
in.

> The fact, the in the current version of the model anything is an
> instance of Object wouldn't make the design better.

"The current version of the model"?

You seem to be missing the point. You are apparently picking one out of
a potential seven billion changes that could be made to Java -- and a
*very* unlikely one at that -- and advocating designing around the
possibility that the language might change in that way. If the language
changes that dramatically, or (far more likely) if you decide on a
different implementation language or write bindings for a different
language, you're going to have a *lot* of porting and adaptation to make
your code work, and whether your API is declared to take an interface
parameter or not in Java is just plain insignificant in that scenario.

So why not design around the possibility that Sun might eliminate
interface types entirely, or that you might switch to a language that
doesn't have those? Or ever better, what about automatic memory
management? Should I be designing my Java APIs to manage who has
responsibility for reclaiming memory, even though it really doesn't need
to be done at all? After all, Sun might change Java to eliminate the
garbage collector, or I might decide to provide a C++ interface to the
library. What then?

> That would be the same as if one method takes a Collection and
> internally assumes that this Collection is a Vector:
>
> public Enumeration getEnumeration( Collection c ) {
> return ((Vector)c).elements();
> }

Well, no it's not. One situation involves a type conversion that's not
guaranteed to succeed. The other involves no conversion at all, but
rather simply using the reference according to its declared interface. 

-- 
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

Relevant Pages

  • Re: Terminology : casting/conversion
    ... Is this an "explicit" cast? ... conversion even if the type of the expression is the ... Here are p & p2 are pointers but the compiler "implicitly" converts ... this parse tree is almost unconnected to the ...
    (comp.lang.c)
  • Re: Integer to Double conversion
    ... > In Delphi, the expression Singlewould be a type cast. ... What I want is to force the compiler to generate a floating point ... IntToExtended or Int64ToExtended conversion function. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Saving C structures to file -- best practices
    ... in an identical way when changing the number of elements or when a new compiler decides to re-arrange them. ... Do the conversion from struct elementto an array element by element, ... A good system design should always separate internal and external data ...
    (comp.arch.embedded)
  • Re: Convert from std::vector<double> to std::vector<int>
    ... >> I fail to see how this is an unnecessary cast. ... What you're talking about is a conversion. ... > The compiler will do the conversion, ... I misdescribed it as casting instead of implicit conversion. ...
    (comp.lang.cpp)
  • Re: Terminology : casting/conversion
    ... Is this an "explicit" cast? ... conversion even if the type of the expression is the ... Here are p & p2 are pointers but the compiler "implicitly" converts ... this parse tree is almost unconnected to the ...
    (comp.lang.c)