🚀 go-pugleaf

Hi All,

Thanks for all your answer, I even got a replay of how to sole the problem
to my mail.

In general it makes no different if the init class is abstract or not.
If I add the following constructor to Sub class:
Sub()
{
    super();
    ...
    ...
}

When I follow the debugger I see that when I create the class I see the
following:
    1. first there is the call to the super constructor (That cause the call
to the init methods in Sub class).
    2. All the Sub class members with default values are initialized.
    3. The Sub class constructor is being executed.

I agree that this behavior is due to the way instance variable are being
initialize
(After the instance object was created), but from my understanding the
object
is created completely, therefore I expect that it first set the default
values
and then start the super constructor.

Isn't this sound more intuitive ?

John Baker <jbaker@SoftComms.com> wrote in message news:3be65bc0_1@dnews...
> Interesting example but I think java is still is working the specified way
> as the super class must be completely contructed before constructing the
> subclass so your field will get overwritten every time.
>
> I wouldn't really recommend this kind of initialization strategy and I
> suspect you are going for some kind custom module type scenario.
>
> More often that not it is better to use an interface as the basis of some
> module and have an adapter class (default implementation for simplicity
like
> MouseAdapter etc) that you extend from. This leaves you the option later
to
> not extend from the base class if necessary (this often happens when a
> program evolves and requirements change). An example if you like..
>
> // The basic skeletal definition of a module
> public interface MyModule
> {
>     public void init();
>     public void open();
>     public void close();
>     public void destroy();
> }
>
> // A convenient adapter class to extend to avoid rewriting every method
> public class MyModuleDefaultImpl implements MyModule
> {
>     public void init() { /* noop - override if req */ }
>     public void open() { /* noop - override if req */ }
>     public void close() { /* noop - override if req */ }
>     public void destroy() { /* noop - override if req */ }
> }
>
> // This
> public class MyModuleImplA extends MyModuleDefaultImpl
> {
>     public void init() { /* override to do something useful */ }
> }
>
> public class HostApp
> {
>     public static void main(String[] args)
>    {
>       try
>       {
>         // Use a dynamically loaded and instantiated module at runtime
>         // Notice we only ever refer to the interface not the actual
> implementation at runtime
>         MyModule m =
(MyModule)Class.forName("MyModuleImplA").newInstance();
>         m.init();
>         m.open(); // etc....
>       }
>       catch (Exception x)
>       {
>          x.printStackTrace();
>       }
>    }
> }
>
>
> Hanan Hermon <hananh@radcom.co.il> wrote in message
news:3be65516_2@dnews...
> > Hi,
> >
> > Below there are to small classes with a main method.
> > When I run it I expected the output to be "Init", but surprisingly it
was
> > "Def".
> >
> > I found out that when we set default values in the class descriptions it
> > is being set after we return from the ancestor constructor.
> >
> > I expected that the default values will be set before the constructor
> > starts.
> >
> > Is this a bug or that is the way it should work ?
> >
> > I'm using JBuilder 4 on Windows-NT.
> >
> > Here ate the classes descriptions:
> >
> > abstract class Base
> > {
> >   abstract public void init();
> >
> >   Base()
> >   {
> >     init();
> >   }
> > }
> >
> >
> > public class Sub extends Base
> > {
> >   private String mTemp = "Def";
> >
> >   public void init()
> >   {
> >     mTemp = "Init";
> >   }
> >
> >   static public void main(String[] args)
> >   {
> >     Sub   tmp = new Sub();
> >
> >     System.out.println(tmp.mTemp); // Expected output is "Init" ?!
> >
> >   }
> > }
> >
> >
>
>