jakarta-bcel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Wilson" <mj.wilson...@googlemail.com>
Subject Re: Bug#: 46254
Date Thu, 08 Jan 2009 20:17:54 GMT
2009/1/6  <zagiatakrapovic@gmx.ch>:
> Hi guys,
>
> The recently opened the bug no. 46254, there I described the problems with dup instructions
as insertion points.
<snip>

I can see the argument for using the very same instance for common
instructions (for example, lower memory footprint).  I think that
using Instruction instances as markers within an InstructionList is
possibly misusing the method; BCEL provides InstructionHandle for this
very purpose.  Let me explain my reasoning...

The problem is that this suggestion is making an Instruction both an
abstraction of a byte-code instruction and also a unique instance of
that byte-code within a particular InstructionList.  Compare what Java
does with Strings  If you write "Hello" in one place and "Hello" in
another, they are the very same object.  But if you read the string
"Hello" from a file, it will almost certainly be a different object,
even though it is equal (to the point of being 100% substitutable).
To complete the analogy, two DUP instances are substitutable (IIRC).

Java deals with the ambiguity of identity in places like
List.indexOf() by stating that it finds the index of the "first
occurrence".

I would be against removing all the common instruction instances (for
example, in InstructionConstants).  I would rather suggest that the
insert method's JavaDoc is improved to clarify what it does.  (All
IMHO, of course.)

Kind regards,
Matthew

---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org


Mime
View raw message