Mailing List Archive

Constructor rules concern for the new `class` syntax
Hello.

Read the documentation for new class syntax in order to make a support in
my IDEA perl support plugin. And one thing perplexed me:

> class and package declarations are similar, but classes automatically get
a constructor named new - You don't have to (and should not) write one.

This is a bit strange, because code like following is pretty usual
(java-like example):

```
class GenericAnimal {
private String myFamily;

public GenericAnimal(String family){
myFamily = family;
}
}
```

```
class GenericCat extends GenericAnimal {
public GenericCat(.... some cat related stuff...){
super("cats");
.... set up cat related stuff
}
}
```
Or
```
class FourLegsAnimal extends GenericAnimal {
public FourLegsAnimal(AnimalDescriptor animalDescriptor){
super(computeFamily(animalDescriptor));
}

private String computeDescriptor(AnimalDescriptor animalDescriptor){
// computing some stuff
}
}
```
So the point is: subclasses may want to amend/compute constructor
parameters for the super-classes.
Re: Constructor rules concern for the new `class` syntax [ In reply to ]
On Sat, Jul 8, 2023 at 1:23?PM Alexandr Evstigneev <hurricup@gmail.com>
wrote:


> This is a bit strange, because code like following is pretty usual
> (java-like example):
>
> ```
> class GenericAnimal {
> private String myFamily;
>
> public GenericAnimal(String family){
> myFamily = family;
> }
> }
> ```
>

I'm aware of that pattern. We don't follow it because there's no real need
to. In particular, you'll note that Java typically doesn't used named
arguments. Perl uses them, Corinna requires them for the the constructor,
so our code is structured differently. Rather than go into long-winded
detail, you can read about class construction here:
https://github.com/Ovid/Cor/blob/master/rfc/class-construction.md

If we need more, we have ADJUST blocks that can be called after object
construction.

Best,
Ovid
--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/
Re: Constructor rules concern for the new `class` syntax [ In reply to ]
On Sat, 8 Jul 2023 15:23:11 +0400
Alexandr Evstigneev <hurricup@gmail.com> wrote:

...
> So the point is: subclasses may want to amend/compute constructor
> parameters for the super-classes.

Yup, that sort of thing is indeed useful sometimes.

We're definitely thinking through various ways to do things like that.

I should remind folks, that Cor and Object::Pad are the places where
the overall design of this thing is being worked on and experimented
with. The parts that have made it here into Perl v5.38 are the smallest
stable bit of distilled "yes we're definitely happy with these parts"
of it. There's a lot more still being worked on elsewhere.

If you have specific thoughts about how subclasses should interact with
construction-time parameters of their parent class(es), please do get
in touch by one of those mechanisms.

https://github.com/Ovid/Cor/wiki/

https://metacpan.org/pod/Object::Pad

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Constructor rules concern for the new `class` syntax [ In reply to ]
> https://github.com/Ovid/Cor/blob/master/rfc/class-construction.md
Thank you, this was educational!

I'm sorry, I don't get how this question is related to the fact of using
named arguments. Superclass has parameters and some subclasses may want to
pass something fixed (or derived from their own parameters). And there is
no way to do that.

So now I have even more questions:

1. How to pass a fixed value/derived value as a parameter to a superclass
constructor without necessity to pass it to the subclass? In theory I can
do that in the ADJUST phaser if superclass provides a setter for it, but
there is no guarantee and this won't work if parent ADJUST relies on that
field being set in construction.
2. Seems there is no mechanism to make constructor parameters mandatory and
I need to write checks myself in the ADJUST phaser, which feels redundant
and automatable work.


On Sun, 9 Jul 2023 at 12:35, Ovid <curtis.poe@gmail.com> wrote:

> On Sat, Jul 8, 2023 at 1:23?PM Alexandr Evstigneev <hurricup@gmail.com>
> wrote:
>
>
>> This is a bit strange, because code like following is pretty usual
>> (java-like example):
>>
>> ```
>> class GenericAnimal {
>> private String myFamily;
>>
>> public GenericAnimal(String family){
>> myFamily = family;
>> }
>> }
>> ```
>>
>
> I'm aware of that pattern. We don't follow it because there's no real need
> to. In particular, you'll note that Java typically doesn't used named
> arguments. Perl uses them, Corinna requires them for the the constructor,
> so our code is structured differently. Rather than go into long-winded
> detail, you can read about class construction here:
> https://github.com/Ovid/Cor/blob/master/rfc/class-construction.md
>
> If we need more, we have ADJUST blocks that can be called after object
> construction.
>
> Best,
> Ovid
> --
> Curtis "Ovid" Poe
> --
> CTO, All Around the World
> World-class software development and consulting
> https://allaroundtheworld.fr/
>
Re: Constructor rules concern for the new `class` syntax [ In reply to ]
> If you have specific thoughts about how subclasses should interact
with construction-time parameters of their parent class(es), please do
get in touch by one of those mechanisms.
> https://github.com/Ovid/Cor/wiki/

Will do, thank you.

On Sun, 9 Jul 2023 at 14:27, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> On Sat, 8 Jul 2023 15:23:11 +0400
> Alexandr Evstigneev <hurricup@gmail.com> wrote:
>
> ...
> > So the point is: subclasses may want to amend/compute constructor
> > parameters for the super-classes.
>
> Yup, that sort of thing is indeed useful sometimes.
>
> We're definitely thinking through various ways to do things like that.
>
> I should remind folks, that Cor and Object::Pad are the places where
> the overall design of this thing is being worked on and experimented
> with. The parts that have made it here into Perl v5.38 are the smallest
> stable bit of distilled "yes we're definitely happy with these parts"
> of it. There's a lot more still being worked on elsewhere.
>
> If you have specific thoughts about how subclasses should interact with
> construction-time parameters of their parent class(es), please do get
> in touch by one of those mechanisms.
>
> https://github.com/Ovid/Cor/wiki/
>
> https://metacpan.org/pod/Object::Pad
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>
Re: Constructor rules concern for the new `class` syntax [ In reply to ]
On Sun, Jul 9, 2023 at 12:29?PM Alexandr Evstigneev <hurricup@gmail.com>
wrote:

> I'm sorry, I don't get how this question is related to the fact of using
> named arguments. Superclass has parameters and some subclasses may want to
> pass something fixed (or derived from their own parameters). And there is
> no way to do that.
>

We're still working with the semantics of ADJUST blocks. This one is a
harder problem and we don't yet have an answer. The "simple" answer is to
ask if subclassing is appropriate and if you should be favoring composition
over inheritance. Of course, the real world is often not that simple and
without seeing a more concrete example, it's hard to know what the right
course of action is.

That's not to dismiss your question: it's very important and gets to the
core of one of the more vexing issues.


> 1. How to pass a fixed value/derived value as a parameter to a superclass
> constructor without necessity to pass it to the subclass? In theory I can
> do that in the ADJUST phaser if superclass provides a setter for it, but
> there is no guarantee and this won't work if parent ADJUST relies on that
> field being set in construction.
>

My comments above cover this: we don't have a great answer for this right
now. Generally speaking the superclass needs to be "assembled" first (not
quite constructed) because subclasses rely on their parent classes.

Composition instead of inheritance makes this trivial to work around, but
obviously that won't always work. Can you send a concrete example?


> 2. Seems there is no mechanism to make constructor parameters mandatory
> and I need to write checks myself in the ADJUST phaser, which feels
> redundant and automatable work.
>

Mandatory parameters are all field variables with a :param but without a
default.

field $mandatory :param;
field $optional :param = 42;

Note that using "= undef" for a default also works, in case you want
optional, but undefined.

Best,
Ovid
Re: Constructor rules concern for the new `class` syntax [ In reply to ]
Should we continue here or move to the gh? Feels counterproductive to have
2 discussions in different places.

On Sun, 9 Jul 2023 at 16:41, Ovid <curtis.poe@gmail.com> wrote:

> On Sun, Jul 9, 2023 at 12:29?PM Alexandr Evstigneev <hurricup@gmail.com>
> wrote:
>
>> I'm sorry, I don't get how this question is related to the fact of using
>> named arguments. Superclass has parameters and some subclasses may want to
>> pass something fixed (or derived from their own parameters). And there is
>> no way to do that.
>>
>
> We're still working with the semantics of ADJUST blocks. This one is a
> harder problem and we don't yet have an answer. The "simple" answer is to
> ask if subclassing is appropriate and if you should be favoring composition
> over inheritance. Of course, the real world is often not that simple and
> without seeing a more concrete example, it's hard to know what the right
> course of action is.
>
> That's not to dismiss your question: it's very important and gets to the
> core of one of the more vexing issues.
>
>
>> 1. How to pass a fixed value/derived value as a parameter to a superclass
>> constructor without necessity to pass it to the subclass? In theory I can
>> do that in the ADJUST phaser if superclass provides a setter for it, but
>> there is no guarantee and this won't work if parent ADJUST relies on that
>> field being set in construction.
>>
>
> My comments above cover this: we don't have a great answer for this right
> now. Generally speaking the superclass needs to be "assembled" first (not
> quite constructed) because subclasses rely on their parent classes.
>
> Composition instead of inheritance makes this trivial to work around, but
> obviously that won't always work. Can you send a concrete example?
>
>
>> 2. Seems there is no mechanism to make constructor parameters mandatory
>> and I need to write checks myself in the ADJUST phaser, which feels
>> redundant and automatable work.
>>
>
> Mandatory parameters are all field variables with a :param but without a
> default.
>
> field $mandatory :param;
> field $optional :param = 42;
>
> Note that using "= undef" for a default also works, in case you want
> optional, but undefined.
>
> Best,
> Ovid
>