Date: Mon, 11 Apr 2022 18:27:22 +0200
pon., 11 kwi 2022 o 18:20 Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> napisaĆ(a):
>
> On Mon, Apr 11, 2022 at 11:32 AM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > On Mon, Apr 11, 2022 at 10:34 AM Marcin Jaczewski wrote:
> >
> > > ```
> > > template<typename... Modifiers>
> > > class Laser
> > > {
> > > std::tuple<Modifiers...> _mod; //could be base classes
> > > void trigger()
> > > {
> > > (get<Modifiers>(_mod).apply(), ...);
> > > }
> > > };
> > > ```
> >
> >
> > I see how that would work, however then you wouldn't be able to deal
> > with a simple "Laser &" or "Laser *".
> >
> > Instead of having simple non-template functions like:
> >
> > void DoSomething(Laser &arg) { . . . }
> >
> > void DoSomethingElse(Laser &arg) { . . . }
> >
> > You would have to complicate it as follows:
> >
> > template<typename... Modifiers>
> > void DoSomething(Laser<Modifiers...> &arg) { . . . }
> >
> > template<typename... Modifiers>
> > void DoSomethingElse(Laser<Modifiers...> &arg) { . . . }
>
> You say that as though your version is *less* complicated. It's just
> complex in a different way. Indeed, the only complexity that template
> functions require is that... you know that it's a template.
>
Not to mention that if we would like to call diffrent lasers by the
same function we can have a base virtual class
`ILaser` that will be a common interface for all `Laser<>`.
This is exactly what solution Arthur O'Dwyer suggest in article he
post in this thread (see last update in it):
https://quuxplusone.github.io/blog/2019/12/03/dress-shirt/
> Containment is typically a better, more maintainable alternative in a
> lot of cases compared to inheritance. This has been demonstrated
> repeatedly over the past 20+ years of the prominence of OOP-based
> designs. Component-based designs typically beat inheritance-based
> designs for large-scale systems, particularly on extensibility and
> maintenance. They are better able to compartmentalize distinct
> systems.
>
> In short, your overall language feature seems to be "let's make it
> easier for people to write bad code", not "let's encourage people to
> write good code."
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
<std-proposals_at_[hidden]> napisaĆ(a):
>
> On Mon, Apr 11, 2022 at 11:32 AM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > On Mon, Apr 11, 2022 at 10:34 AM Marcin Jaczewski wrote:
> >
> > > ```
> > > template<typename... Modifiers>
> > > class Laser
> > > {
> > > std::tuple<Modifiers...> _mod; //could be base classes
> > > void trigger()
> > > {
> > > (get<Modifiers>(_mod).apply(), ...);
> > > }
> > > };
> > > ```
> >
> >
> > I see how that would work, however then you wouldn't be able to deal
> > with a simple "Laser &" or "Laser *".
> >
> > Instead of having simple non-template functions like:
> >
> > void DoSomething(Laser &arg) { . . . }
> >
> > void DoSomethingElse(Laser &arg) { . . . }
> >
> > You would have to complicate it as follows:
> >
> > template<typename... Modifiers>
> > void DoSomething(Laser<Modifiers...> &arg) { . . . }
> >
> > template<typename... Modifiers>
> > void DoSomethingElse(Laser<Modifiers...> &arg) { . . . }
>
> You say that as though your version is *less* complicated. It's just
> complex in a different way. Indeed, the only complexity that template
> functions require is that... you know that it's a template.
>
Not to mention that if we would like to call diffrent lasers by the
same function we can have a base virtual class
`ILaser` that will be a common interface for all `Laser<>`.
This is exactly what solution Arthur O'Dwyer suggest in article he
post in this thread (see last update in it):
https://quuxplusone.github.io/blog/2019/12/03/dress-shirt/
> Containment is typically a better, more maintainable alternative in a
> lot of cases compared to inheritance. This has been demonstrated
> repeatedly over the past 20+ years of the prominence of OOP-based
> designs. Component-based designs typically beat inheritance-based
> designs for large-scale systems, particularly on extensibility and
> maintenance. They are better able to compartmentalize distinct
> systems.
>
> In short, your overall language feature seems to be "let's make it
> easier for people to write bad code", not "let's encourage people to
> write good code."
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2022-04-11 16:27:33