Hi Rajith,
Usage of the serialization is/will be configurable through Sandesha --
Matt said that he would be adding code to do that (if it isn't there
already.) If the serialization doesn't get invoked, then all that will
occur will be a few no-op method invocations.
I don't agree with point 5 being a "definite no no." I believe that it
is a matter of personal preference and if the author of the code
believes that it makes it easier to read and doesn't create issues then
so be it. Any reasonable editor today will have no difficulty locating
the definition if you need to look at it.
As I said, I certainly welcome any concerned party to show me (in
hard/accurate numbers) where the code does not perform and it will be
addressed.
-Bill
On Wed, 2007-01-31 at 10:24 -0500, Rajith Attapattu wrote:
> I do have one question for Anne, is this serialization configurable ?
> In other words can I switch off this behaviour if I don't want it?
> (Pardon me for not going through the code to figure this out )
>
> I also share the same concerns as Deepal about code conventions.
> No matter what coding convention was followed, point 5 is a definite
> no no.
>
> Sanjiva, I am glad that you are requesting some benchmarking, I was
> consistently proposing that Anne should subject this code through some
> high volume message scenarios to figure out the performance impact.
>
> The basis for my objections was that the overhead introduced by this
> feature, out weighs the benefits of it. YMMV
>
> Rajith
>
> On 1/29/07, Deepal Jayasinghe <[EMAIL PROTECTED]> wrote:
> Hi Bill,
>
> >
> >>Among the all , the most worst thing I saw in the code is
> following kind
> >>of things, I strongly believe we should not have this kind
> of code in
> >>the code base, If you found such kind of code please point
> out them then
> >>and there.
> >>
> >> - String tmpClassNameStr = "null"; (is this the way we
> initialize to
> >>NULL )
> >> - String tmpHasList = "no list"
> >> - Unnecessary casting
> >> - A number of unused variables
> >> - Variable declarations here and there (as an example
> private static
> >>final String - selfManagedDataDelimiter = "*";)
> >>
> >>
> >
> >I'm indifferent on the first two; in some cases it makes the
> code easier
> >to read and debug at the cost of an assignment and space in
> the string
> >table.
> >
> Well , more focus should be for code readability than
> debugging .
>
> >The third one should be caught by any decent compiler and
> >eliminated (so long as you're not casting back and forth) and
> again
> >sometimes enhances readability so I'm indifferent on this one
> as well.
> >I agree on the fourth -- I don't think that there's ever a
> good case for
> >extraneous variables. The fifth is again a code readability
> issue and
> >one of the reasons that Java doesn't require that you declare
> everything
> >up front.
> >
> >
> Thank's for trying to clarify all these points. Just hope not
> everybody
> will start writing code like this :-)
>
> BTW in point 5, I was talking about class level 'public
> static'
> variables, not method level variables.
> For e.g.
>
> class {
> public static v1;
> method1 ();
> public static v2();
> method2();
> }
>
> I dont think this is the way to go.
>
> Deepal.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
