the purpose of marker interface in java - Java Help

AppletTalk.com
Java discussions newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

the purpose of marker interface in java
Goto page 1, 2 Next

AppletTalk.com Forum Index -> Java Help

View previous topic :: View next topic

Author

Message

jrefactors@hotmail.com
Guest

Posted: Mon Jun 13, 2005 6:24 pm Post subject: the purpose of marker interface in java

I know what is marker interface - An interface with no methods. Example: Serializable, Remote, Cloneable. But I don't know the purpose of using marker interface, and when is the good practice for that. Please advise. thanks!!

Matt Humphrey
Guest

Posted: Mon Jun 13, 2005 7:17 pm Post subject: Re: the purpose of marker interface in java

<jrefactors (AT) hotmail (DOT) com> wrote

Quote:

I know what is marker interface - An interface with no methods.
Example: Serializable, Remote, Cloneable.

But I don't know the purpose of using marker interface, and when is the
good practice for that.

Please advise. thanks!!

Sometimes different kinds of objects are differentiated without having any
different methods or properties. Marker interfaces allow a program to
determine if an object has some characteristic and behave accordingly.
Consider the following example: I have a system that has a dozen different
kinds of objects that are manipulated by the user: Person, Vehicle,
RealEstate, Property, Spouse, Dependent, etc. There is no meaningful
inheritance hierarchy that contains them all. Perhaps some of these
represent and so have to be managed by special privacy rules. This can be
done by making up and marking them with a "Privacy" interface tag. When the
UI manipulates objects, it treats those that are "Privacy" instances
differently. Similarly, some could also be marked as for other purposes.
Often the marking has more to do with the programmatic mechanics of the
object rather than its semantics and there's a fine line between what
constitutes good design for using marker interfaces versus a good design for
classes in general.

Cheers,
Matt Humphrey [email]matth (AT) ivizNOSPAM (DOT) com[/email] http://www.iviz.com

Stefan Schulz
Guest

Posted: Mon Jun 13, 2005 7:22 pm Post subject: Re: the purpose of marker interface in java

On Mon, 13 Jun 2005 11:24:48 -0700, jrefactors wrote:

Quote:

For 1.5, i would not use marker interfaces at all anymore. Use a
Runtime-Retained annotation.

Generally, they are used to give additional information about the
behaviour of a class. The possibly best example is the RandomAccess
interface... the worst offender probably Cloneable.

--
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper

Thomas G. Marshall
Guest

Posted: Mon Jun 13, 2005 9:50 pm Post subject: Re: the purpose of marker interface in java

Matt Humphrey coughed up:

Quote:

jrefactors (AT) hotmail (DOT) com> wrote in message
news:1118687088.660230.65400 (AT) g49g2000cwa (DOT) googlegroups.com...
I know what is marker interface - An interface with no methods.
Example: Serializable, Remote, Cloneable.

But I don't know the purpose of using marker interface, and when is
the good practice for that.

Please advise. thanks!!

Sometimes different kinds of objects are differentiated without
having any different methods or properties. Marker interfaces allow
a program to determine if an object has some characteristic and
behave accordingly. Consider the following example: I have a system
that has a dozen different kinds of objects that are manipulated by
the user: Person, Vehicle, RealEstate, Property, Spouse, Dependent,
etc. There is no meaningful inheritance hierarchy that contains them
all.

Yes.

However, it should be noted that because an empty interface is by definition
establishing no behavior (other than the obvious "no behavior" behavior
Smile

Chris Uppal
Guest

Posted: Tue Jun 14, 2005 8:16 am Post subject: Re: the purpose of marker interface in java

Stefan Schulz wrote:

Quote:

For 1.5, i would not use marker interfaces at all anymore. Use a
Runtime-Retained annotation.

Just BTW, has anyone looked at the performance of the runtime annotations ?

-- chris

Matt Humphrey
Guest

Posted: Tue Jun 14, 2005 2:24 pm Post subject: Re: the purpose of marker interface in java

"Thomas G. Marshall" <tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com>
wrote in message news:0dnre.2108$aR1.1401 (AT) trndny02 (DOT) ..

Quote:

Matt Humphrey coughed up:
[email]jrefactors (AT) hotmail (DOT) com[/email]> wrote in message
news:1118687088.660230.65400 (AT) g49g2000cwa (DOT) googlegroups.com...
I know what is marker interface - An interface with no methods.
Example: Serializable, Remote, Cloneable.

But I don't know the purpose of using marker interface, and when is
the good practice for that.

Please advise. thanks!!

Sometimes different kinds of objects are differentiated without
having any different methods or properties. Marker interfaces allow
a program to determine if an object has some characteristic and
behave accordingly. Consider the following example: I have a system
that has a dozen different kinds of objects that are manipulated by
the user: Person, Vehicle, RealEstate, Property, Spouse, Dependent,
etc. There is no meaningful inheritance hierarchy that contains them
all.

Yes.

However, it should be noted that because an empty interface is by
definition
establishing no behavior (other than the obvious "no behavior" behavior
Smile

I'm not convinced. Your downcast is required because you want to treat the
object as a Bug, not because it's Pocketable. The marker interface is
really only used to distinguish between those objects that have the marker
and those that don't. In your example, knowing that all the objects are
Pocketable isn't meaningful--they might as well have all been Object. Some
other part of the program needs to change its behavior based on whether or
not the object has the marker.

Quote:

For simply collecting the objects together however, it is very useful.
That's pretty much it's only purpose.

Cheers,
Matt Humphrey [email]matth (AT) ivizNOSPAM (DOT) com[/email] http://www.iviz.com/

Tor Iver Wilhelmsen
Guest

Posted: Tue Jun 14, 2005 3:03 pm Post subject: Re: the purpose of marker interface in java

Stefan Schulz <terra (AT) spacetime (DOT) de> writes:

Quote:

For 1.5, i would not use marker interfaces at all anymore. Use a
Runtime-Retained annotation.

Except that

object instanceof MarkerInterface

is easier than

object.getClass().isAnnotationPresent(MarkerAnnotation.class)

Thomas G. Marshall
Guest

Posted: Tue Jun 14, 2005 6:22 pm Post subject: Re: the purpose of marker interface in java

Matt Humphrey coughed up:

Quote:

"Thomas G. Marshall"
[email]tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com[/email]> wrote in
message news:0dnre.2108$aR1.1401 (AT) trndny02 (DOT) ..
Matt Humphrey coughed up:
[email]jrefactors (AT) hotmail (DOT) com[/email]> wrote in message
news:1118687088.660230.65400 (AT) g49g2000cwa (DOT) googlegroups.com...
I know what is marker interface - An interface with no methods.
Example: Serializable, Remote, Cloneable.

But I don't know the purpose of using marker interface, and when is
the good practice for that.

Please advise. thanks!!

Sometimes different kinds of objects are differentiated without
having any different methods or properties. Marker interfaces allow
a program to determine if an object has some characteristic and
behave accordingly. Consider the following example: I have a system
that has a dozen different kinds of objects that are manipulated by
the user: Person, Vehicle, RealEstate, Property, Spouse, Dependent,
etc. There is no meaningful inheritance hierarchy that contains
them all.

Yes.

However, it should be noted that because an empty interface is by
definition establishing no behavior (other than the obvious "no
behavior" behavior Smile

What do you think I'm trying to convince you of?

Quote:

Your downcast is required because you want to
treat the object as a Bug, not because it's Pocketable.

Correct. I have a bunch of things in my pocket, and I wish to do something
to only the bugs.

Quote:

The marker
interface is really only used to distinguish between those objects
that have the marker and those that don't.

Sure. As in my example.

Quote:

In your example, knowing
that all the objects are Pocketable isn't meaningful--they might as
well have all been Object.

*NO* !

The array is an array of only things that can be in a pocket. Had I made it
an array of Object, it would have had no type safety whatsoever. One of the
things in my pocket might *well* have been a car or house at a later point
in time, added by a very tired engineer!!!

Quote:

Some other part of the program needs to
change its behavior based on whether or not the object has the marker.

That's embodied entirely in the loop. It's a loop entirely of the array,
which is entirely /only/ of things that /can/ be and are in my pocket.

Quote:

For simply collecting the objects together however, it is very
useful.
That's pretty much it's only purpose.

And once you do that, you then do /what/ with it?

Tell me how you would build an array of things that are only pocketable,
when you cannot use a common superclass?

Realize that the purpose of my post was to supply what was some of the
baggage was about marker interfaces. That you need to do a downcast, while
not strictly a no-no even for the OO purists in comp.object, is not ideal.

--
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

Thomas G. Marshall
Guest

Posted: Tue Jun 14, 2005 6:23 pm Post subject: Re: the purpose of marker interface in java

Thomas G. Marshall coughed up:

Quote:

Matt Humphrey coughed up:
"Thomas G. Marshall"
[email]tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com[/email]> wrote in
message news:0dnre.2108$aR1.1401 (AT) trndny02 (DOT) ..
Matt Humphrey coughed up:
[email]jrefactors (AT) hotmail (DOT) com[/email]> wrote in message
news:1118687088.660230.65400 (AT) g49g2000cwa (DOT) googlegroups.com...
I know what is marker interface - An interface with no methods.
Example: Serializable, Remote, Cloneable.

But I don't know the purpose of using marker interface, and when
is the good practice for that.

Please advise. thanks!!

Sometimes different kinds of objects are differentiated without
having any different methods or properties. Marker interfaces
allow a program to determine if an object has some characteristic
and behave accordingly. Consider the following example: I have a
system that has a dozen different kinds of objects that are
manipulated by the user: Person, Vehicle, RealEstate, Property,
Spouse, Dependent, etc. There is no meaningful inheritance
hierarchy that contains them all.

Yes.

However, it should be noted that because an empty interface is by
definition establishing no behavior (other than the obvious "no
behavior" behavior Smile

), downcasting is often required to actually
accomplish something.

Example:

public interface Pocketable {}

public class Apple {...} implements Pocketable
public class Bug {...} implements Pocketable, Gross
public class CarKeys{...} implements Pocketable

Pocketable[] inPocket = {new Apple(), new Bug(), new CarKeys()};

for (int i = 0; i if (inPocket[i] instanceof Bug)
((Bug)inPocket[i]).pullLegsOff(3); // required
downcast

I'm not convinced.

What do you think I'm trying to convince you of?

Your downcast is required because you want to
treat the object as a Bug, not because it's Pocketable.

Correct. I have a bunch of things in my pocket, and I wish to do
something to only the bugs.

The marker
interface is really only used to distinguish between those objects
that have the marker and those that don't.

Sure. As in my example.

In your example, knowing
that all the objects are Pocketable isn't meaningful--they might as
well have all been Object.

*NO* !

The array is an array of only things that can be in a pocket. Had I
made it an array of Object, it would have had no type safety
whatsoever. One of the things in my pocket might *well* have been a
car or house at a later point in time, added by a very tired
engineer!!!

Some other part of the program needs to
change its behavior based on whether or not the object has the
marker.

That's embodied entirely in the loop. It's a loop entirely of the
array, which is entirely /only/ of things that /can/ be and are in my
pocket.

For simply collecting the objects together however, it is very
useful.
That's pretty much it's only purpose.

And once you do that, you then do /what/ with it?

Tell me how you would build an array of things that are only
pocketable, when you cannot use a common superclass?

Realize that the purpose of my post was to supply what was some of the
baggage was about marker interfaces. That you need to do a downcast,
while not strictly a no-no even for the OO purists in comp.object, is
not ideal.

The point of "downcast" in this regard is of course added to the good or bad
issue of RTTI, as in my example.

--
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

Matt Humphrey
Guest

Posted: Tue Jun 14, 2005 10:26 pm Post subject: Re: the purpose of marker interface in java

"Thomas G. Marshall" <tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com>
wrote in message news:%gFre.5926$qr1.1199 (AT) trndny07 (DOT) ..

Quote:

Thomas G. Marshall coughed up:
Matt Humphrey coughed up:
"Thomas G. Marshall"
[email]tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com[/email]> wrote in
message news:0dnre.2108$aR1.1401 (AT) trndny02 (DOT) ..
Matt Humphrey coughed up:
[email]jrefactors (AT) hotmail (DOT) com[/email]> wrote in message
news:1118687088.660230.65400 (AT) g49g2000cwa (DOT) googlegroups.com...
I know what is marker interface - An interface with no methods.
Example: Serializable, Remote, Cloneable.

But I don't know the purpose of using marker interface, and when
is the good practice for that.

Please advise. thanks!!

Sometimes different kinds of objects are differentiated without
having any different methods or properties. Marker interfaces
allow a program to determine if an object has some characteristic
and behave accordingly. Consider the following example: I have a
system that has a dozen different kinds of objects that are
manipulated by the user: Person, Vehicle, RealEstate, Property,
Spouse, Dependent, etc. There is no meaningful inheritance
hierarchy that contains them all.

Yes.

However, it should be noted that because an empty interface is by
definition establishing no behavior (other than the obvious "no
behavior" behavior Smile

That marker interfaces often require downcasting in order to accomplish
something. Marker interfaces are only identify some objects out of a larger
collection. I believe that what you do with those objects (and any
downcasting required) is a separate issue. The typical marker interfaces
for Cloneable, etc don't require any downcasting at all. If you're
identifying objects in order to do something special (not in the superclass
interface) with them, it seems a regular interface would be more
appropriate. I see a more typical marker interface example as:

UserItem [] userItems = getMyItems (userId);
for (int i = 0; i < userItems.length; ++i) {
if (userItems[i] instanceof Pocketable) {
userItem[i].discard ();
}
}

Discarding is a general operation on UserItem. But I'm only discarding
Pocketable items.

Quote:

Your downcast is required because you want to
treat the object as a Bug, not because it's Pocketable.

Correct. I have a bunch of things in my pocket, and I wish to do
something to only the bugs.

Which really has nothing to do with marker interfaces. If you wanted to do
something only to the Bugs, why not just select on Bug to begin with?

Quote:

The marker
interface is really only used to distinguish between those objects
that have the marker and those that don't.

Sure. As in my example.

In your example, knowing
that all the objects are Pocketable isn't meaningful--they might as
well have all been Object.

*NO* !

The array is an array of only things that can be in a pocket. Had I
made it an array of Object, it would have had no type safety
whatsoever. One of the things in my pocket might *well* have been a
car or house at a later point in time, added by a very tired
engineer!!!

Although that's certainly true, I don't think I'll start marking all the
objects in my systems as "MyAppObject" just to make sure no one slips in
objects from some other application Smile

Quote:

The marker is useful for building the collection, not for using it. If the
point is to collect a subset of objects and do something special and unique
to them that is not otherwise defined by a superclass, you probably should
be using a real interface. Similarly, if the objects are all subclasses of
some common superclass (whether it's Object, etc), it is still useful to
distinguish some object classes from others (e.g. Clonable, Mutable,
Externalizable, etc) even though the behavior will still be defined through
the superclass.

Quote:

Realize that the purpose of my post was to supply what was some of the
baggage was about marker interfaces. That you need to do a downcast,
while not strictly a no-no even for the OO purists in comp.object, is
not ideal.

The point of "downcast" in this regard is of course added to the good or
bad
issue of RTTI, as in my example.

I think your point is well made that marker interfaces don't help with
determining behavior. I just happen to see that as an issue more to do with
defining and handling subclass behavior than with marker interfaces.

Cheers,
Matt Humphrey [email]matth (AT) ivizNOSPAM (DOT) com[/email] http://www.iviz.com/

Thomas G. Marshall
Guest

Posted: Tue Jun 14, 2005 11:36 pm Post subject: Re: the purpose of marker interface in java

Matt Humphrey coughed up:

Quote:

"Thomas G. Marshall"
[email]tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com[/email]> wrote in
message news:%gFre.5926$qr1.1199 (AT) trndny07 (DOT) ..
Thomas G. Marshall coughed up:
Matt Humphrey coughed up:
"Thomas G. Marshall"
[email]tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com[/email]> wrote in
message news:0dnre.2108$aR1.1401 (AT) trndny02 (DOT) ..
Matt Humphrey coughed up:
[email]jrefactors (AT) hotmail (DOT) com[/email]> wrote in message
news:1118687088.660230.65400 (AT) g49g2000cwa (DOT) googlegroups.com...
I know what is marker interface - An interface with no methods.
Example: Serializable, Remote, Cloneable.

But I don't know the purpose of using marker interface, and when
is the good practice for that.

Please advise. thanks!!

Sometimes different kinds of objects are differentiated without
having any different methods or properties. Marker interfaces
allow a program to determine if an object has some characteristic
and behave accordingly. Consider the following example: I have a
system that has a dozen different kinds of objects that are
manipulated by the user: Person, Vehicle, RealEstate, Property,
Spouse, Dependent, etc. There is no meaningful inheritance
hierarchy that contains them all.

Yes.

However, it should be noted that because an empty interface is by
definition establishing no behavior (other than the obvious "no
behavior" behavior Smile

But you're not disagreeing then. To /do/ anything with that object often
requires downcasting to some type that /has/ the behavior you need.

Quote:

The typical marker interfaces for Cloneable, etc don't require any
downcasting at all.

Wrong! First of all, clone() lives in Object, but does not work unless you
use the marker interface, but that doesn't bend the rules any. If you
decide to make an array of Cloneable items:

Cloneable[] cloneableItems = {...};

then you *have* to downcast if you wish to access things (behaviors) that
don't exist in Object.

We should stay clear of discussing interface here. Cloneable is a
particularly weird built-in case, which has nothing to do with any marker
interfaces a user might concoct on his own, the reasons for doing so being
the topic of this discussion.

Quote:

If you're identifying objects in order to do
something special (not in the superclass interface) with them, it
seems a regular interface would be more appropriate. I see a more
typical marker interface example as:

UserItem [] userItems = getMyItems (userId);
for (int i = 0; i < userItems.length; ++i) {
if (userItems[i] instanceof Pocketable) {
userItem[i].discard ();
}
}

Discarding is a general operation on UserItem. But I'm only
discarding Pocketable items.

{Sigh}. These Pocketable items----how do you define them? I have given you
an example of an apple, a bug, and a set of car keys, each their own class.
If they were already inheriting from some other types (something that is
part of their individual hierarchies) then how do I write code to:

1. model the collection of items in my pocket.
2. write code to pull the legs off of all the bugs in my pocket.

You *cannot*, unless you provide the code example I gave.

Quote:

Your downcast is required because you want to
treat the object as a Bug, not because it's Pocketable.

Correct. I have a bunch of things in my pocket, and I wish to do
something to only the bugs.

Which really has nothing to do with marker interfaces. If you wanted
to do something only to the Bugs, why not just select on Bug to begin
with?

What are you talking about? And collect them in my pocket how? The
identifier "inPocket" is an array of things to hold in my pocket. You have
3 choices here:

1. Make the array of some common superclass that holds all the behavior I
need.
2. Make the array of some common superclass that is just "high enough" to
hold them all. You mentioned Object.
3. Make the array of some common interface.

I cannot do 1, because as I said, the superclasses are already established
as something else.
I can do 2, but then I don't have any type safety, and I *STILL* have to
downcast anyway (!) to operate on the bugs in my pocket. The option #3 is
the clear alternative.

....[rip]...

Quote:

In your example, knowing
that all the objects are Pocketable isn't meaningful--they might as
well have all been Object.

*NO* !

The array is an array of only things that can be in a pocket. Had I
made it an array of Object, it would have had no type safety
whatsoever. One of the things in my pocket might *well* have been a
car or house at a later point in time, added by a very tired
engineer!!!

Although that's certainly true, I don't think I'll start marking all
the objects in my systems as "MyAppObject" just to make sure no one
slips in objects from some other application Smile

(?) Is there a point here?

Let's look at it this way, perhaps you'll understand this better:

You're tasked with modeling a person.
The person is associated with 0..1 pairs of pants. (he could be naked).
The Pants have a pocket.
The pocket holds anything Pocketable, any number of disparate objects in the
system.
You need to operate on items that are only *in the pocket*, and in this
case, you need to pull the legs off of any bugs in your pocket.

Quote:

Some other part of the program needs to
change its behavior based on whether or not the object has the
marker.

That's embodied entirely in the loop. It's a loop entirely of the
array, which is entirely /only/ of things that /can/ be and are in
my pocket.

For simply collecting the objects together however, it is very
useful.
That's pretty much it's only purpose.

And once you do that, you then do /what/ with it?

Tell me how you would build an array of things that are only
pocketable, when you cannot use a common superclass?

The marker is useful for building the collection, not for using it.
If the point is to collect a subset of objects and do something
special and unique to them that is not otherwise defined by a
superclass, you probably should be using a real interface.

With what behavior in that interface? Write the code to do what my code
did: Maintain a pocket of items that are only meant for a pocket. And pull
the legs off of all the bugs in the pocket.

....[rip]...

Quote:

I think your point is well made that marker interfaces don't help with
determining behavior. I just happen to see that as an issue more to
do with defining and handling subclass behavior than with marker
interfaces.

These are disparate objects, only knit together in that they are pocketable.
Again, I'll repeat, "when you cannot use a common superclass".

--
Whyowhydidn'tsunmakejavarequireanuppercaselettertostartclassnames....

Thomas G. Marshall
Guest

Posted: Tue Jun 14, 2005 11:38 pm Post subject: Re: the purpose of marker interface in java

Tor Iver Wilhelmsen coughed up:

Quote:

Stefan Schulz <terra (AT) spacetime (DOT) de> writes:

For 1.5, i would not use marker interfaces at all anymore. Use a
Runtime-Retained annotation.

Except that

object instanceof MarkerInterface

is easier than

object.getClass().isAnnotationPresent(MarkerAnnotation.class)

I think so too. I'm not sure why someone would want to avoid it.

I'm assuming that it has to do with an aversion to the following:

1. RTTI
2. downcasting

But there are times when both are the clearest thing to do.

--
Whyowhydidn'tsunmakejavarequireanuppercaselettertostartclassnames....

Dale King
Guest

Posted: Wed Jun 15, 2005 3:44 am Post subject: Re: the purpose of marker interface in java

Matt Humphrey wrote:

Quote:

"Thomas G. Marshall"

[and so on back and forth]

Quote:

I'm not really taking a side on this, but Cloneable is not really a
valid example for the general case of marker interfaces. It doesn't have
to downcast because it has its implementation in the common superclass
Object. That sort of agrees with Thomas' point because as he was noting
that one issue with marker interfaces is that you don't have the common
superclass, but in the case of Cloneable you actually do. The same
however cannot be said for the general case of marker interfaces.

--
Dale King

Thomas G. Marshall
Guest

Posted: Wed Jun 15, 2005 4:07 am Post subject: Re: the purpose of marker interface in java

Dale King coughed up:

Quote:

Matt Humphrey wrote:
"Thomas G. Marshall"
[email]tgm2tothe10thpower (AT) replacetextwithnumber (DOT) hotmail.com[/email]

[and so on back and forth]

That marker interfaces often require downcasting in order to
accomplish something. Marker interfaces are only identify some
objects out of a larger collection. I believe that what you do with
those objects (and any downcasting required) is a separate issue. The
typical marker interfaces for Cloneable, etc don't require any
downcasting at all.

I'm not really taking a side on this, but Cloneable is not really a
valid example for the general case of marker interfaces. It doesn't
have to downcast because it has its implementation in the common
superclass Object. That sort of agrees with Thomas' point because as
he was noting that one issue with marker interfaces is that you don't
have the common superclass, but in the case of Cloneable you actually
do. The same however cannot be said for the general case of marker
interfaces.

As I pointed out in my last post, Cloneable is indeed an odd duck that
doesn't belong in this conversation, because while /everything/ (marker
interface or not) has access to Object, the actual intended usage of
Cloneable is for accessing something within Object without downcasting.

There is little wonder that Cloneable causes so much ire, particularly among
the purists. Sun apparently did not want a Cloneable.clone() interface
method because clone() would need to exist within Object anyway (it is best
implemented as something native), Object would need to implement Cloneable,
which would mean that every single object in the known universe would be
cloneable. {shrug} Which doesn't somehow seem so bad to me.

--
Framsticks. 3D Artificial Life evolution. You can see the creatures
that evolve and how they interact, hunt, swim, etc. (Unaffiliated with
me). http://www.frams.alife.pl/

Stefan Schulz
Guest

Posted: Wed Jun 15, 2005 4:48 am Post subject: Re: the purpose of marker interface in java

On Wed, 15 Jun 2005 04:07:24 +0000, Thomas G. Marshall wrote:

Quote:

Dale King coughed up:
There is little wonder that Cloneable causes so much ire, particularly among
the purists. Sun apparently did not want a Cloneable.clone() interface
method because clone() would need to exist within Object anyway (it is best
implemented as something native), Object would need to implement Cloneable,
which would mean that every single object in the known universe would be
cloneable. {shrug} Which doesn't somehow seem so bad to me.

I would at least have expected a public Object clone(); in Cloneable.
Leaving the method abstract does make very little sense to me. Okay, so
you can, in theory, have the ability to make an Object cloneable without
actually exposing the clone() method... but how often does that happen?

--
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper

Display posts from previous:

	AppletTalk.com Forum Index -> Java Help	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum