🚀 go-pugleaf

Thanks for your discussion of working around final methods. My wording "throw an
event", instead of "generate an event", misled you. I was not trying to throw
exceptions. My apologies. Nevertheless, your comments on tracing taught me
something new.

My work around on not being able to override Vector's final methods was to
create methods with similar names in my VectorPart subclass, e.g.
deleteElement(...) was re-incarnated as deletePart(...), which is coded to all
that deleteElement does, plus it generates the event I want.

Thanks again for your response.

John Collins wrote:

> Declaring methods final allows the compiler, if it wishes, to inline the
> code... basically making it a typed-checked macro instead of a subroutine
> call.  It runs faster and in the case of really short subroutines actually
> takes less code.  Of course the compiler is not _required_ to do so.
>
> Also, declaring a method as final prevents a user of the class from
> overriding functionality you feel would make the class unsound if altered.
> Not sure if that was a concern with Vector or not.
>
> Since you are using JBuilder I would think that as an alternative to
> overriding these methods you could, if you were interested in tracing, just
> enable tracing for "java" (package) classes and then put a breakpoint on the
> "insert" and "delete" methods.  Then change the properties of the
> breakpoints to logging and not stopping.
>
> Now throwing a Runtime (unchecked) exception is possible but probably not
> beneficial.  Throwing a checked exception is probably not possible since
> that would change the signature of the function (interface, not merely
> implementation).
>
> I question why you would want to throw an exception when an element is
> inserted and deleted.  Exceptions are not really events.  They are aborts
> and the caller would have to try/catch the exception every place the insert
> or delete operators were used in your code or standard or 3rd party code
> that used a Vector.  Perhaps I just don't grasp something obvious about what
> you are trying to do.
>
> If you just want to check some of your own code you could create a proxy or
> facade class that would contain a private standard java.util.Vector class,
> which would provide as much of the Vector classes interface as you needed
> and forward all calls to the internal java.util.Vector class.  You could
> call your own code in this case, before and after the insert was actually
> carried out.
>
> If you want to spy on what code that you didn't write is doing then I
> suggest going the debugger route instead.
>
> bill wrote in message <3549CE7D.1BA40EB4@xsite.net>...
> >Hi Foks,
> >
> >I wanted to subclass java.util.Vector so that my vector would throw
> >events when an element was inserted or deleted. Not easily done. The
> >insert and remove methods in Vector are final and cant be overridden.
> >I'll find a workaround, but why are the above methods defined as final ?
> >
> >Thanks,
> >
> >Bill.
> >