[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info
From: |
Dan Eble |
Subject: |
Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden) |
Date: |
Tue, 12 Jun 2018 23:23:56 -0400 |
On Jun 12, 2018, at 18:18, address@hidden wrote:
>
> The tradeoff of having people know about dynamic casting and using it
> properly needs to be matched with people not needing to know about
> dynamic casting and being able to ignore it.
Carl, I appreciate hearing your perspective and I’d like to continue this
discussion to the point of reaching a consensus on the design.
I perceive that we understand each other’s points and simply disagree. There
is nothing new I want to counter with. I will just state that if a contributor
were made uncomfortable by dynamic_cast, my two-pronged solution would be (1)
gently encourage him to educate himself on this fundamental feature of C++, and
(2) over time, rework the software to require fewer casts by preserving more
type information in the internal interfaces and pushing the casts outward
toward the interface with Scheme.
> As I said before, I'm not asking for a reversion. I think I just have a
> different tradeoff value model than you have.
Clearly, and I’m sure David can contribute a third perspective, and I hope he
will choose to.
This attempted clean-up and some other work in progress has been about as
engaging as pounding sand down a rat hole, and I have only persevered in it
because I considered it a step in the direction of a cleaner system in the long
run. If it is valuable, then I would be willing to continue, but if that is
not the general perception, then I would rather take one step back, restore the
code to an acceptable state (probably not quite a straight reversion, though),
and never touch it again.
Thence, back to consensus: From what I’ve seen, the existing approach in many
(most?) cases is that any kind of grob can be passed to any function and if
it’s the right kind of grob, you get what you asked for, and if it’s the wrong
kind of grob, you get something else. I can see that this is necessary at the
interface between Scheme and C++, but it doesn’t have to be carried through to
all the C++ internals, with each step working to determine the specific type
information it requires but neglecting to propagate it to the next step. That
loose approach could be continued, but it doesn’t have to be. Should it be
continued?
Regards,
—
Dan
- Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden), nine . fierce . ballads, 2018/06/11
- Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden), nine . fierce . ballads, 2018/06/11
- Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden), nine . fierce . ballads, 2018/06/12
- Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden), Carl . D . Sorensen, 2018/06/12
- Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden),
Dan Eble <=
- Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden), dak, 2018/06/13
- Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden), Carl . D . Sorensen, 2018/06/13
- Re: Issue 5336: Remove downcasting methods from Grob_array and Grob_info (issue 344010043 by address@hidden), Carl . D . Sorensen, 2018/06/13