Extended derived types default initialization

[GianLuigi Piacentini]

Hi all,

I have a base type from which say 2 extended types are derived.
The reason behind is that base type provides type components and some
(mostly access) procedures, extended types differ only in the procedures
(methods?) that are applicable to each extended type. Internal
components are the same.
All types are declared in their own module.
Only the extended types should appear in user code.

The point is, I need default initialization different in each extended
type (very short example follows - in any previous code I wrote I didn't
use extended types this way)

module base_mod
type base_t
real :: a(3)
..
module d1_t
use base_mod
type, extends(base_t) :: d1_t
base_t = [0., 0., 0.]
..
module d2_t
use base_mod
type, extends(base_t) :: d2_t
base_t = [1., 1., 1.]

or something else ?

Thanks in advance
Gigi

[rbader]

It is not possible to specify default initialization of the base type's component in an extension.
However, if only the extended type is visible in user code, why not use two differently initialized base types,
with the same name for the type component?

Regards
Reinhold

[JRR]

Am 11.11.21 um 11:29 schrieb GianLuigi Piacentini:

What I usually do is a deferred initalizer for the abstract type, which
then gets different implementation for the extended types.

--
Juergen Reuter
Theoretical Particle Physics
Deutsches Elektronen-Synchrotron (DESY)
Hamburg, Germany

[gah4]

On Thursday, November 11, 2021 at 4:30:49 AM UTC-8, rbader wrote:
> GianLuigi Piacentini schrieb am Donnerstag, 11. November 2021 um 11:29:18 UTC+1:

> > I have a base type from which say 2 extended types are derived.

(snip)

> > The point is, I need default initialization different in each extended
> > type (very short example follows - in any previous code I wrote I didn't
> > use extended types this way)

(snip)

> It is not possible to specify default initialization of the base type's component in an extension.
> However, if only the extended type is visible in user code, why not use two differently initialized base types,
> with the same name for the type component?

I think you can do it in Java.

That is, I don't think the restriction is basic to OOP.

If only the extended types are used, it is usual to make the
base abstract. But also, as noted, if the base is never used,
put the variable declaration in each extended type.

I presume that there are other parts to the base, though it
should work either way.

[GianLuigi Piacentini]

On 11/11/21 13:30, rbader wrote:

>
> It is not possible to specify default initialization of the base type's component in an extension.
> However, if only the extended type is visible in user code, why not use two differently initialized base types,
> with the same name for the type component?

Reinhold

do you intend something like (omitting lot of details)

module base_mod
providing base type definition and methods acting on base type (say for
example set, get, print).
This module will be never seen by the code end-user (that will interact
only with what is exported by modules dt1_mod and dt2_mod).
Everything is public, so that it may be freely accessed inside dt1_mod
and dt2_mod

module dt1_mod
use base_mod
type :: dt1_t
private
type(base_t) :: base_component = dt1 default initialization
!-- no dt1-specialized type component
end type dt1_t
public:: dt1_t, "common" methods, dt1-specialized methods
contains
"common" methods, basically written on the spirit of
subroutine get_dt1 ( (instance, stuff)
type(dt1_t), intent(in) :: instance
.. intent(out) :: stuff
call get_base (dt1%base_component, stuff)
!-- no dt1-specialized components, so nothing else to do
end subroutine get_dt1
..
dt1-specialized methods (a fair number of procedures)
end module dt1_mod

module dt2_mod
use base_mod
type :: dt2_t
private
type(base_t) :: base_component = dt2 default initialization
!-- no dt2-specialized type component
end type dt2_t
public:: dt2_t, "common" methods, dt2-specialized methods
contains
"common" methods, basically written on the spirit of
subroutine get_dt2 ( (instance, stuff)
type(dt2_t), intent(in) :: instance
.. intent(out) :: stuff
call get_base (dt2%base_component, stuff)
!-- no dt2-specialized components, so nothing else to do
end subroutine get_dt2
..
dt2-specialized methods (a fair number of procedures)
end module dt2_mod

Well, that's a possibility, thanks. I have to say that I do not like it
that much, but, as we say here in Italy "bisogna fare di necessita'
virtu'" (= that may be very freely translated as "catch as you can").

Thanks
Gigi

[GianLuigi Piacentini]

On 11/11/21 20:17, gah4 wrote:
> I think you can do it in Java.
>
> That is, I don't think the restriction is basic to OOP.
>
> If only the extended types are used, it is usual to make the
> base abstract.

Yes, but I have also base type procedures (say get, set, print and some
other things) that are common to both extended types, and I would like
to leverage this commonalty.

> But also, as noted, if the base is never used,
> put the variable declaration in each extended type.

That's a possibility, and is what I did in previous code on similar
problems: what I called "extended types" in my example, were written as
completely independent types, that happened to have some procedures
differing only in argument type definitions. In the end, some very
small include files containing set, get print and other common stuff
internals.

>
> I presume that there are other parts to the base, though it
> should work either way.
>

Thanks
Gigi
>

[gah4]

On Friday, November 12, 2021 at 2:07:47 AM UTC-8, GianLuigi Piacentini wrote:
> On 11/11/21 20:17, gah4 wrote:
> > I think you can do it in Java.

> > That is, I don't think the restriction is basic to OOP.

> > If only the extended types are used, it is usual to make the
> > base abstract.

> Yes, but I have also base type procedures (say get, set, print and some
> other things) that are common to both extended types, and I would like
> to leverage this commonalty.

Thinking about this again, it seems to me that it is more usual to initialize
instance variables in the constructor. Now that you mention it, I am not
sure why, in those cases where they could be initializers. (They are just
called initializers, not default initializers.) Note that by default (without
an initializer) instance variables in Java are 0, false, or null. Static
variables are also initialized to 0, false, or null without any help.
For local variables, though, Java requires that the compiler be able
to determine that they are initialized before they are used.

Doing it in the constructor allows for more complicated initialization,
such as loops or other things that can't go into a single expression.

It seems to me that yours could be done in the constructor.