[prev in list] [next in list] [prev in thread] [next in thread] 

List:       flightgear-devel
Subject:    Re: [Flightgear-devel] Terrain for AI-Tests
From:       Midnight Ploughboy <midnight.ploughboy () gmail ! com>
Date:       2022-09-29 7:52:18
Message-ID: CAC86-y+KqKZNgKrWDphqtm8K2ZAoXpLt=KBYQKmXL+0tdni80w () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Thanks for the confirmation. I'll go that way then. You do realise the
benefit of the completely dynamic linking of Java.

Keith

On Thu, Sep 29, 2022 at 8:57 AM James Turner <james@flightgear.org> wrote:

>
>
> > On 28 Sep 2022, at 20:45, Keith Paterson <midnight.ploughboy@gmail.com>
> wrote:
> >
> > I can get this to return a FGMockScenery (subclass of FGScenery), but of
> course all the calls to FGScenery go to the superclass without me being
> able to intercept. So the only way would to make a abstract superclass for
> FGMockScenery and FGScenery. Is that correct? I wish it Java. Mockito FTW.
>
> You can make an abstract superclass or better make FGScenery the abstract
> one (easier on the rest of the code), rename the current implementation to
> FGDefaultScenery, and make your FGMockScenery alongside.
>
> You'll need to make various methods virtual, such as (presumably)
> get_elevation_m, get_cart_elevation_m, ..
>
> Depending on how much of an object-orientated purist you want to be, you
> could keep the various ref_ptr<foo_branch> member variables and their
> public getters in the superclass : this would mean it's not a true abstract
> interface but would save some virtual methods and keep your mock simpler.
> But do whatever suits you better in this area.
>
>

[Attachment #5 (text/html)]

<div dir="ltr"><div dir="ltr">Thanks  for the confirmation. I&#39;ll go that way \
then. You do realise the benefit of the completely dynamic linking of Java.  \
<div><br></div><div>Keith</div></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Sep 29, 2022 at 8:57 AM James Turner &lt;<a \
href="mailto:james@flightgear.org">james@flightgear.org</a>&gt; \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br>
&gt; On 28 Sep 2022, at 20:45, Keith Paterson &lt;<a \
href="mailto:midnight.ploughboy@gmail.com" \
target="_blank">midnight.ploughboy@gmail.com</a>&gt; wrote:<br> &gt; <br>
&gt; I can get this to return a FGMockScenery (subclass of FGScenery), but of course \
all the calls to FGScenery go to the superclass without me being able to intercept. \
So the only way would to make a abstract superclass for FGMockScenery and FGScenery. \
Is that correct? I wish it Java. Mockito FTW.<br> <br>
You can make an abstract superclass or better make FGScenery the abstract one (easier \
on the rest of the code), rename the current implementation to FGDefaultScenery, and \
make your FGMockScenery alongside.<br> <br>
You'll need to make various methods virtual, such as (presumably) get_elevation_m, \
get_cart_elevation_m, ..   <br> <br>
Depending on how much of an object-orientated purist you want to be, you could keep \
the various ref_ptr&lt;foo_branch&gt; member variables and their public getters in \
the superclass : this would mean it's not a true abstract interface but would save \
some virtual methods and keep your mock simpler. But do whatever suits you better in \
this area.<br><br> </blockquote></div></div>





_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[prev in list] [next in list] [prev in thread] [next in thread]