Re: svn commit: r153332 -jakarta/bcel/trunk/src/java/org/apache/bcel/verifier/structurals/OperandStack.java

Thanks for the reminder, and certainly agree with the principle.. It seemed 
to me that size() being a 'const' and 'primal' method is safe to expose, as 
no matter what kind of stack you have, it's going to have a size.
If folks feel different, i'd be glad to revert.

.
----- Original Message ----- 
From: "Simon Kitching" <[email protected]>
To: "BCEL Developers List" <[email protected]>
Sent: Thursday, February 10, 2005 10:43 PM
Subject: Re: svn commit: 
r153332 -jakarta/bcel/trunk/src/java/org/apache/bcel/verifier/structurals/OperandStack.java


> On Fri, 2005-02-11 at 03:17 +0000, [email protected] wrote:
>> Author: dbrosius
>> Date: Thu Feb 10 19:17:49 2005
>> New Revision: 153332
>>
>> URL: http://svn.apache.org/viewcvs?view=rev&rev=153332
>> Log:
>> Apply Patch 27646 from Stephan Michels to change method 
>> OperandStack.size() to be public
>
> Hi Dave,
>
> I'm sure you're well aware of this, and that this email is not necesary.
> But I have to earn my keep as BCEL list member :-)
>
> Once some method/variable/class/whatever has been made "public" or
> "protected", it then takes a major version change to get rid of it
> again, as it is generally frowned upon to break user code in a minor
> version release.
>
> And having too much stuff public can make it difficult sometimes to
> introduce new optimisations or even to fix bugs.
>
> If it really makes logical sense for the OperandStack to be public, then
> fine. I just wanted to remind you of the "backwards compatibility"
> burden that is associated with promoting something from internal
> (package or private) to external (public or protected) visibility.
>
> Cheers,
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>